Comments on: Dual Master Git Repositories http://allmybrain.com/2009/11/17/dual-master-git-repositories/ Where stuff from my brain lands Sat, 05 May 2012 12:28:56 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Dennis http://allmybrain.com/2009/11/17/dual-master-git-repositories/comment-page-1/#comment-977 Dennis Wed, 18 Nov 2009 17:58:48 +0000 http://allmybrain.com/?p=330#comment-977 The cool thing is, you can really do about whatever you want. We use bare server repos all the time. Sometimes, I work on a couple machines, but I don't want to push to the server repo (not ready for co-workers to get the updates etc). I can push back and forth between my machines, edit until I like things, then finally push to the server. I could also share some changes with a co-worker, but not push to the server. When I finally push and he pulls, git is smart enough to not have a single issue. git isn't perfect but it sure beats older scm technology. The cool thing is, you can really do about whatever you want. We use bare server repos all the time. Sometimes, I work on a couple machines, but I don’t want to push to the server repo (not ready for co-workers to get the updates etc). I can push back and forth between my machines, edit until I like things, then finally push to the server. I could also share some changes with a co-worker, but not push to the server. When I finally push and he pulls, git is smart enough to not have a single issue. git isn’t perfect but it sure beats older scm technology.

]]> By: Hans Fugal http://allmybrain.com/2009/11/17/dual-master-git-repositories/comment-page-1/#comment-976 Hans Fugal Wed, 18 Nov 2009 17:51:06 +0000 http://allmybrain.com/?p=330#comment-976 A better way is to have a bare "hub" repository that you push/pull from each repository. But I admit that I do something similar to you, but I have settled on a pattern that's a bit more predictable and easier to recover from when i screw it up: I set up the repo on "server", then clone it on "laptop". Then I edit .git/config on laptop and add this line to the remote (named origin by default): [remote "origin"] ... push = +refs/heads/*:refs/remotes/laptop/* Then when I do git push everything is pushed but no HEAD is changed and no working directory is messed up. Then on server I do git merge laptop. You can also work with multiple branches, etc. Likewise when you git fetch server, you have the freedom to merge or rebase or whatever you want to do explicitly on the server's status. Or you can git pull of course. The only thing to watch for is occasionally you'll want to do a git remote prune to clean up the old branches that you deleted but whose deletion didn't get propagated. A better way is to have a bare “hub” repository that you push/pull from each repository. But I admit that I do something similar to you, but I have settled on a pattern that’s a bit more predictable and easier to recover from when i screw it up:

I set up the repo on “server”, then clone it on “laptop”. Then I edit .git/config on laptop and add this line to the remote (named origin by default):

[remote "origin"]
…
push = +refs/heads/*:refs/remotes/laptop/*

Then when I do git push everything is pushed but no HEAD is changed and no working directory is messed up. Then on server I do git merge laptop. You can also work with multiple branches, etc.

Likewise when you git fetch server, you have the freedom to merge or rebase or whatever you want to do explicitly on the server’s status. Or you can git pull of course.

The only thing to watch for is occasionally you’ll want to do a git remote prune to clean up the old branches that you deleted but whose deletion didn’t get propagated.

]]>