Back Story
Earlier this month Frysk switched to using git from cvs.
As developers we used this tutorial to get started:
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
Which was a great starting point, but with all the merging the remote repository had a lot of noise, of people resolving conflicts recommitting and re-pushing.
Tim Moore suggested we use git fetch then git rebase instead of git pull. Thats when things went a little weird for me I messed up my repo a couple of times but seem to have gotten the hang of it. The trick is to always type git fetch origin and git rebase origin and not just ‘git rebase’
Getting Productive
I started getting git when I unlearned CVS knowledge, and ignored the existence of the remote repository. By doing that I got rid of all the confusion resulting from trying to depend on the remote repo, and trying to figure out which commands contacted witch repo.
At first I didnt really understand the distributed work flow. I was making my changes, and pushing all day long. This in combination with my attempt to commit often and commit early resulted in a lot of overhead.
Here is what I did:
- Make changes
- Run test suit
- Updated my tree (git fetch+rebase, cvs update)
- Rebuild (this usually means rebuilding the entirety of frysk since other developers my have made changes to underlying code)
- If build is broken fix it or ask someone else for a fix and wait…
- Run test suit if a test is broken fix or ask for a fix and wait…
- Publish my changes (git push, cvs commit)
- Test the build/test suit from an independent virgin checkout. (again build the entire Frysk tree)
On a good day I end up with two commits.
With a distributed version control system, namely git, I run the test suit and commit. As often as I want. Most of the patches are small and contain one fictional change. I accumulated all these commits in my local repo. At the end of the day (or when I have something worth sharing) I do a rebase and a push, and test the build/test suit from a virgin checkout.
I can do diffs, roll backs, all the power of a VCS without going over the network… or talking to sourceware.org
.
Given this kind of work flow the noise merging might now be so loud and using rebase might now be necessary. Personally I will continue to use rebase.
Tips:
- Use git rebase to bring in relevant changes upstream without having to commit.
- Use git reset –soft HEAD^ to undo the last commit and bring it back from the index to you tree
- Use git clean to git rid of unwanted artifacts.
- Use git diff to see what/where conflect are.