Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
git is a decentralized versioning tool and git always makes a local copy of your repo when cloning, the concept about a "centralized" or "unique" repository simply does not exist in git's world in global terms. –  user827992 Jul 10 '12 at 19:21
1  
@user827992 I am fully 100% aware of that fact. I don't think I suggested anything about centralizing. The only thing I was referring to is if you are using a fileshare, one machine is the host, in the sense that it's physically storing the files. That's a concept wholly apart from dvcs. –  Tesserex Jul 10 '12 at 19:52
add comment

4 Answers

If not all the machines are up all the time, there's no silver bullet: before shutting down the machine, you have to push the changes somewhere else. I push to a private server, but it could just as well be dropbox or a usb key you carry everywhere.

Yes, pushing multiple branches to a central place can get tedious, but that shouldn't be too difficult to script. I use a push.sh script for that, which I run every time I'm done working on a machine.

share|improve this answer
add comment

I've come at this from a slightly different direction (and I use mercurial, but philosophically its the same). This isn't my idea, I just use it and it works for my personal stuff.

I created a clone of my repositories in a SkyDrive folder (it could equally be dropbox or another magic sync tool of your choice), I have then configured the instances on my two machines to automatically push to the SkyDrive repository on commit.

When I switch boxes its then just a matter of doing a pull and an update - in theory you'll always be working in a linear fashion even though its in multiple repositories.

The key here is that the SkyDrive repo exists mostly to provide a means to ensure that I've got access to more or less the latest version of the code on both my machines - though it would work as well for more - and to provide an extra backup. Anything that is "done" gets pushed to Kiln (if I were using git and I correctly understand the way the game is played then that would be point at which I do a rebase).

What I really wouldn't want to do is run off a shared folder... if you're using a DVCS then you may as well enjoy the benefit.

share|improve this answer
add comment

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> :
share|improve this answer
add comment

The first of your two alternatives is the answer. That's implied by the "D" in "DVCS". Each user has their own local instance of the repository, and the repositories talk amongst themselves in manageable ways.

You could do your second alternative, but the problem is, there's only one repository working directory. So the work tree can be in only one state at a time--there's no Joe working on one branch and Jane working on another. So developers can overwrite each other's changes, mangle each other's work. Why, it's like not having version control at all!

There's a middle ground called, having a bare repository on a network drive, and having individual users check in and out of it. This separates your WIP work (which yes, you keep locally) from the work you publish up to the repository. It's not "save" up--it's "publish". The work you want your peers to see and use.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.