I have a several branches in my repository and I'm finding that over time it's becoming more difficult to keep them all up to date. I can always be sure that master is up to date because it's easy to remember and I suppose it's my SVN mentality still lingering on.
- master
- bugfix1
- bugfix2
- newfeature
- experiment
My problem is something like this. I make changes in the bugfix2 branch, I merge the c开发者_开发技巧hanges in to master once I've done my commit, but then I have several other branches out of date. I have to manually merge bugfix2 in to every other branch. As my branch list grows, I think it's unrealistic to perform all these merge operations.
Is there a command for this or is my workflow wrong?
The general workflow is to merge from the most specific branch to a less specific branch.
But for a bug needed to be reported to all other branches, a simple merge to the other branches is enough and can be scripted (even aliased):
for i in $branches; do
git checkout $i
git merge bugfix2
done
My advice is to merge whatever you need into whatever branch you're currently working on, and don't worry about keeping the rest up to date until the next time you work on them. One of the reasons I use git locally on top of my company's centralized VCS is that it allows branches to be a little out of date. The bug that's hard to reproduce can be worked against the exact version it was reported against. New features can be debugged without wondering if it was your change that caused the problem or the update you just pulled down in order to push a separate fix. By all means, don't let your branches diverge too far from master
, but don't be religious about keeping them always up to date "just because." Update them at the best time for the individual branch.
My suggested workflow would be to rebase your bugfix branches on master, once master goes ahead. So your history remains clean and doesn't contain that much merge commits.
精彩评论