How to maintain long running git branches

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 th开发者_StackOverflow中文版e 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?

---

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

---

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.

---

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.