views:

53

answers:

2

I use git to maintain multiple working copies of my code. The idea is that I can check out any branch, build and run it to see how the branch's feature x fits in with the current state of the code.

Git's master branch is the Trunk and the other git branches are features or things I would like to try out. Therefore, my typical usage is updating the master with the latest fixes and then merging master into the individual branches so each of them stays up to date.

This system works well for me, except for the fact that I have to checkout a branch, merge the master and rinse/repeat for the other branches. Given a version control system like git, I don't see this scaling very well given the fact that I'd be prone to spawning a lot of branches over time.

I'm still a git beginner, so I suspect there may be a mechanism of sorts that git already has that I might be missing. Is there one? If not, how does one commit a change to all branches so they stay up to date on their own?

+1  A: 

One possibility (not tested myself) would be:

  • to establish a bare repo where you can push your master branch.
  • have a post-receive hook (see githooks man page) on that bare repo which will then push master on every "feature" repo you want
  • have a post-receive hook per feature repo to begin:
    • a rebase of your feature branch on top of master (fine if you did not yet pushed your feature branch elsewhere)
    • or a merge of master on your feature branch.

You will still need to get to your feature repo and check if the rebase or merge is not blocked due to some merge conflicts.

VonC
Yes, I will need to manually resolve any merge conflicts. Thanks. I had no idea that hooks even existed. I have some reading to do: http://kernel.org/pub/software/scm/git/docs/githooks.html
carleeto
@carleeto: good point, I have added the githooks man page link in my answer.
VonC
@VonC This sounds like you are suggesting multiple repositories instead of multiple branches.
Abizern
@Abizern: true, my first interpretation of the OP's question was being able to be able to checkout, examine and compile several features *at the same time* (hence the all cloning issue). But I may have misinterpreted the question here.
VonC
+1  A: 

If

  1. the branches which you want to merge the latest master commits into are not published AND
  2. you want all commits in master to be in the other branches

then you could simply rebase them onto master after master has been updated. This little script might work if you're using a Unix shell. It rebases each branch onto master.

for BRANCH in `ls .git/refs/heads`; do git rebase master $BRANCH; done
Frerich Raabe