16

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?

Aify
  • 3,543
  • 3
  • 24
  • 43
Carl
  • 43,122
  • 10
  • 80
  • 104
  • Do you have the code implementation of that question ? – edi9999 Jan 25 '14 at 23:06
  • No, it was quite a manual process initially. This was also when I was a git beginner. I am now using git flow, which is very similar, but does not require me to maintain several scripts. – Carl Jan 26 '14 at 20:15

3 Answers3

9

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
  • 90,689
  • 19
  • 115
  • 207
  • 3
    Fantastic! I prefer merging rather than rebasing: ```for BRANCH in `ls .git/refs/heads`; do git checkout $BRANCH; git merge master; done``` And after I push to origin: ```for BRANCH in `ls .git/refs/heads`; do git push origin $BRANCH; done``` – Boris Yakubchik Feb 27 '19 at 14:59
6

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
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 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 – Carl Feb 24 '10 at 22:22
  • @carleeto: good point, I have added the githooks man page link in my answer. – VonC Feb 24 '10 at 22:28
  • This sounds like you are suggesting multiple repositories instead of multiple branches. – Abizern Feb 25 '10 at 08:37
  • @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 Feb 25 '10 at 08:47
  • @edi9999 No, I do not. – VonC Jan 26 '14 at 07:01
3

The following checks out each branch and does the merge

for BRANCH in $(ls .git/refs/heads);
  do git checkout $BRANCH ; 
  git merge origin/master $BRANCH ; 
done
NearHuscarl
  • 66,950
  • 18
  • 261
  • 230
3manuek
  • 907
  • 8
  • 11