git and two machines

Brent Simmons wrote recently about his experiences trying to switch to git for version control.

His complaints about it being more steps to push changes back from his laptop to a desktop machine are quite correct vs. Subversion or Perforce there is an extra (annoying if even somewhat mechanical) step.

He also complains about the work required to update the desktop machine to see those changes pushed from the laptop. Brent doesn’t detail his steps (as he says he always had trouble remembering), but I wonder if he didn’t make the same mistake I initially made when I setup a similar workflow.

The key is to actually have two branches on the desktop machine – in my case I use a convention like this to name my branches: task_work & desktop_task_work 

The remote branch on the laptop tracks task_work and is called laptop_task_work (whilst you could reuse branch names on the laptop it seems easier to me to maintain the convention).

Now to push work from the laptop you need the (additional) step of 

git push

after changes have been committed.

Then on the desktop machine you can do

git rebase task_work

in the desktop_task_work branch to merge those changes pushed from the laptop to the desktop branch where you’re working.

The key thing is this (seemingly redundant) branch linking the two machines. Without it you’re pushing into a branch which may have active checkouts or ongoing work. Switching to the desktop machine and updating that branch to incorporate the changes from the laptop is much more cumbersome, especially if you have any pending changes – in fact it’s so cumbersome that I can’t remember the steps/commands !

Lastly – If you have changes you wish to share with the laptop then you can use 

git merge desktop_task_work

in the task_work branch to merge those changes, then do 

git pull

On the laptop to fetch those changes. You can also of course merge an upstream branch (perhaps a ‘master’ or ‘main’ branch into the task_work branch and then pull/rebase each of the per-machine working branches as you wish).

All this pushing and pulling is certainly more steps than using a single central repository in the style of subversion or perforce, but the lack of central repository is the point of distributed version control. Sadly there has to be some price to pay for it – it seems.

Posted under Uncategorized

This post was written by awk on March 11, 2009

Leave a Comment

Name (required)

Email (required)



More Blog Post