24

Git branches ideally should last for short time, probably for 1-2 days. Then it gets merged into some mainline.

But in some cases, where we work on very big features, we maintain branches. And when 2 or 3 people each work on these very big features in exclusive areas of code, it becomes kinda tough to maintain them.

Amidst hot fixes that go to stable branch, we need to keep these 2-3 big branches in sync with the stable branch. So we end up doing this, quite often.

(in feature-branch1) $ git merge stable
(in feature-branch2) $ git merge stable
(in feature-branch3) $ git merge stable

Is there a right way to maintain these long running branches in git? By doing the above, the git history is kind of messy. These feature branches mostly get pushed to a remote which means that we cannot see rebase as an option. What else can I do?

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
Anand
  • 10,310
  • 24
  • 90
  • 135

3 Answers3

17

Merging in the stable branch every now and then is actually the easiest and best thing you can do to keep your feature branch up to date. I wouldn't recommend rebasing because there might be more people working on the feature at the same time and they would have to reset their local branches a lot every time there was a forced push. Even if only one person works on the feature branch, merging is better because it clearly shows the point in history where you brought in fixes from the stable branch.

Yes, your history can look kind of messy once you merge the feature branch back into stable. But as long as you're avoiding the mess of daily micro-merges from your git pulls (use git pull --rebase instead), you will be able to appreciate actual meaningful merges.

If you really want to avoid merging in new features from stable into the feature branch, but just want bugfixes, you can cherry-pick bugfixes into the feature branch. However this can be a lot of work because it requires that you're always on top of everything that's happening in stable. Use git cherry to help you out:

# commits from "stable" that are not present in
# the current branch will be prefixed with "+"
git cherry HEAD stable
mislav
  • 14,919
  • 8
  • 47
  • 63
  • I had some weird experiences when merging master into a feature branch. Sometimes changes in master won't make into the feature branch (someone kinda messed with the merge step), and then when the feature branch finally merged back to master those master changes were gone, and even more, the place where they disappeared doesn't show up on git's history. For this reason we always merge feature branch into master, then push that again to the feature branch and continue working (without touching the remote master). Kinda http://stackoverflow.com/questions/17527276/git-code-disappeared-after-merge – Rivera Dec 04 '13 at 06:43
2

Rebasing is possible if the team is small enough, and consists of reasonably experienced git users.

What you can do is, for instance, agree that the feature-branch will be rebased on stable every night. Or you could send an email when you rebase the feature-branch to stable.

Everything should be fine, but in case you forget to sync with the rebased feature branch, say you committed C on top of the old feature branch oldFB, which has been rebased into oldFB':

S1 - oldFB - C <-- feature-branch
    \
     S2 - oldFB' - D <-- origin/feature-branch

It is still possible to rebase your commit(s) C by running:

git checkout feature-branch
git rebase --onto origin/feature-branch oldFB C

Note that you'll have to find manually the commit called oldFB in the diagram above.

Olivier Verdier
  • 46,998
  • 29
  • 98
  • 90
  • 2
    When I'm rebasing a long-lived branch, I tend to create a new branch based on it with a new name to avoid collaborators have to deal with rewritten history. (e.g. `git checkout tiresome-feature2; git checkout -b tiresome-feature3; git rebase master`.) Then you just have to tell collaborators that you're working on that new branch now, and they can rebase onto it if they want. – Mark Longair Oct 13 '11 at 10:49
  • 1
    @MarkLongair: that does avoid them having to deal with forced pushes, but they do have to remember switch to the new branches and sometimes bring their local changes over to it. That results in the same amount of work, so you didn't gain much in the end. – mislav Oct 13 '11 at 12:45
  • 1
    @mislav: It's significantly easier in my experience, but I guess it depends a lot on the people involved :) – Mark Longair Oct 13 '11 at 14:25
0

The best option is to merge only the required small bugfix/feature branches into your long-lived feature branches. This way you only get what you need. Note that if you let these branches live long enough, they could ultimately get fairly out of sync from master. From time to time, you might want to create a temporary branch off of your long-lived feature branch, and merge master into it just to do sanity checks - see if there are conflicts, see if changes in master break the feature, and so on.

Next best would be to periodically merge master into your long-lived feature branches. This is fairly safe, but can also merge in a lot of changes you aren't interested in, and complicate things.

I would not recommend rebasing periodically onto master. It makes it tough for everyone to stay in sync, and it also makes it much more difficult to maintain complex history (merges) on your feature branches, and makes the conflict resolution more of a pain.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
  • I learned that you (or your teammates!) should never merge your stable branch (master) _into_ your feature branch because some stable changes may get accidentally discarded! Always merge from your feature into your master branch locally. Then you can pull your local master as a remote feature branch. – Rivera Sep 24 '13 at 07:27