Using Git (was: Re: lfs-chat Digest, Vol 1223, Issue 1)

Andy Bennett andyjpb at
Tue Sep 13 01:28:58 PDT 2011


> There are plenty of git tutorials out there, but none that seem to 
> describe the following workflow I use:

What you describe is similar to how we use git at work.

git clone

> 1) Checkout sources (svn co)

git fetch origin
git checkout master
git merge origin/master or git reset --hard origin/master

> 2) Make a change and commit it locally (quilt new, quilt add, edit 
> files, quilt refresh)
> 3) Make a 2nd change and commit it locally (quilt new, quilt add, edit 
> files, quilt refresh)

git gui / git status, git add & git commit.

> 4) 'Rewind' to the 1st change, as I need to make a change to the first 
> commit (quilt pop, edit files, quilt refresh)
> 5) 'Fast forward' to the 2nd change, to ensure it still applies on top 
> of the first (quilt push)

git rebase -i HEAD^^^

> 6) Rewind both changes, update from upstream so that I have all the 
> latest changes, then do a final 'fast forward' of both changes to ensure 
> they both apply cleanly on top of the latest upstream changes

git fetch origin
git rebase origin/master

> 7) Rewind both changes again, 'fast forward' each change in turn and 
> commit them upstream (quilt pop -a, quilt push, svn ci, quilt push, svn ci)

git push
...will send everything at once.
The rebase from step 6 will ensure that the branch is clean and ready to go.

> Maybe I'm just misunderstanding the tutorials I've read and they may be 
> describing the above, but if anyone could tell me what the git commands 
> are for the above or point to a git cookbook type document, that would 
> be great.  Or, even suggestions on how git has better features for the 
> above would be great too.

You're right: the tutorials are light on this stuff.

'git rebase' and 'git rebase -i' are very powerful and probably what you
want to learn. The interactive (-i) mode is particularly useful. It
gives you a list of commits in your editor and allows you to reapply
them unchanged (pick), merge them with the previous commit (squash) or
get them ready for editing (edit).
After you've made your decisions git runs through the actions, stopping
when there's an edit to make or a commit message to write.

'gitk --all' is useful for visualising what's going on. Before I rebase
I sometimes put a tag where I am so that it hangs around in the
visualisation. I can then eyeball the results or run a 'git diff' to
convince myself I've done the right thing. For more advanced "branch
recovery" check out 'git reflog --help'.

'git mergetool -t vimdiff' is also quite handy but quite daunting at first.
You can select your own diff tool but I find vimdiff to be most reliably
available without configuration.
When a merge conflict occurs the mergetool will give you each conflicted
file in turn. In vimdiff you'll get three panes: one version on the
left, one version on the right and then the "merged" version in the
middle with the traditional "<<<<", ">>>>" and "====" merge markers. Fix
up the version in the middle to how you want it to be, save it and quit.
mergetool will then move onto the next conflict for you.

The git man pages (git <command> --help) tend to be pretty extensive.
This doesn't mean that they're easy to read. It's often good to have a
little bit of knowledge of which order commands arrived in as the
earlier ones tend to better explain the base concepts that the later
ones build on.

Good luck and feel free to contact me with any more questions that arise.


andyjpb at

More information about the lfs-chat mailing list