Git – Working with Git on multiple machines

dvcsgitworkflows

This may sound a bit strange, but I'm wondering about a good way to work in Git from multiple machines networked together in some way. It looks to me like I have two options, and I can see benefits on both sides:

  • Use git itself for sharing, each machine has its own repo and you have to fetch between them.
    • You can work on either machine even if the other is offline. This by itself is pretty big I think.
  • Use one repo that is shared over the network between machines.
    • No need to do git pulls every time you switch machines, since your code is always up to date.
    • Never worry that you forgot to push code from your other non-hosting machine, which is now out of reach, since you were working off a fileshare on this machine.

My intuition says that everyone generally goes with the first option. But the downside I see is that you might not always be able to access code from your other machines, and I certainly don't want to push all my WIP branches to github at the end of every day. I also don't want to have to leave my computers on all the time so I can fetch from them directly. Lastly a minor point is that all the git commands to keep multiple branches up to date can get tedious.

Is there a third handle on this situation? Maybe some third party tools are available that help make this process easier? If you deal with this situation regularly, what do you suggest?

Best Answer

I deal with both of your proposed solutions daily. There are two key concepts to handling them well.

  1. Use topic branches. I believe production history should be pristine. As a result I spend a great deal of time making my production branch's history logical, replicable, and debuggable. When using multiple machines, however, you occasionally need to commit work in progress. Use a topic branch. You can pull and push this branch from both machines with little effort, and when it's ready to merge into master or production rebase it to create a more maintainable history.
  2. Using one repo shared over a network is fine, unless you're also sharing it with other users. We use a shared repository for scripts, creatively named the scripts repository. At first it seemed like a good idea as the repo doesn't change often, but over time it's become quite a nightmare. It's easy to overwrite one another's work, and you end up spending as much time air traffic controlling who's deploying the repository as you do working in it.

The best solution is keeping a local repository on each machine and sharing topic branches between them via a remote. Commit work in progress to those branches as often as you'd like. As long as you're willing to rebase them into a more intelligible history, it's quite effective in practice.

If you find yourself working on more than one topic branch throughout the day but don't want to push each one individually to the remote, git push <remote> will by default push all matching branches to <remote>. This default will change in a later version of git, but can be overrode by setting push.default in a configuration file or by specifying the matching refspec: 

git push <remote> :
Related Topic