Two machine workflow with git

For SCM, our project is using the new hotness in version control – git, hosted on  For a good long while, I was the only contributor who was using the repository there.  When you’re the only contributor, you can get away with sins that aren’t acceptable when you’re part of a team.  Sins like pushing half-baked code to your SCM as you move back and forth between two machines (I have both a laptop and desktop machine).  But, once you’ve brought others into your team and started hooking up continuous integration services like RunCodeRun, this practice is no longer cool.

Like many new to git, it took awhile to get past the centralized mindset that had been pounded into my brain by years and years of thinking of CVS and SVN as the be-all and end-all of how you did these things.  Solving my problem of switching machines without impacting my teammates is one of those things that helps to rewire my thinking.  I how have four git remote’s that I use regularly.  The first three were set up for me more or less without me knowing what was really going on:

origin – aka – the main point of sharing by the development team and where RunCodeRun watches for updates to verify as part of the continuous integration process

staging – hosted on the outstanding Heroku platform, this is where code goes when we’re ready for review by our business stakeholders

demo – also on Heroku, this is an environment that is intended to be more stable than staging.  While staging changes daily (perhaps multiple times), we generally rev demo only once ever couple of weeks

The fourth remote is the subject of this post however.  It’s called “justme” and is actually hosted on my laptop.  I use it to shuttle code back and forth between my laptop and desktop machines.  I can use this to commit all of the sins I used to commit when only I was working on the project.  For example, if I’m working out somewhere on my laptop on some feature and don’t quite get done before I get home.  And now I want to finish up my work on the desktop machine which has significantly better hardware.  Tests not passing?  No problem – just “git push justme mydevbranch” on the laptop and then “get pull justme mydevbranch” on the desktop.  Once my work is finished and I verify tests are passing, I can share the code with my other team members from the desktop with “git push origin somebranch” (or just “git push” for some branches like master).

To set this up on a Mac:

1. On the laptop, create a bare repository somewhere.  For example

mkdir $HOME/src/justme

cd $HOME/src/justme

git clone –bare projectname.git.

2. On the laptop, go to your normal working directory and add a remote to this new area with something like:

git remote add justme $HOME/src/justme/projectname.git

3. On the desktop, add the remote with something like:

git remote add justme userid@laptop.local:src/justme/projectname.git

4. Make sure ssh access is enabled on your laptop (Remote Login option of the Sharing Preference Pane under System Preferences)

5. Make sure the git directory is in your PATH for SSH users on your laptop.  For me, this meant adding this to my ~/.bashrc file:

export PATH=$PATH:/usr/local/git/bin

And you should be good to go.

As I said before, embracing the distributed nature of git is not something that comes easily – especially if you cut your teeth in a world where everything was centralized.  But, once you understand how it works and can put it to your advantage, you really appreciate the benefits of git.

3 thoughts on “Two machine workflow with git”

    1. You could do that too, but that also comes with other side effects. For example, we have a post-commit hook setup on git to notify a Campfire room every time a shared commit is made. The intent is for us to use that to notify each other when “new and interesting stuff is available”. If I’m pushing my personal work through github, it adds some noise to that signal.

Leave a Reply