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.

  • git push doesn't working?
  • Git Alternative : Any suggestion
  • How does visual studio 2013 remember the mapping between a remote git/tfs repository and a local path?
  • Git stash apply leaves extra string in files
  • How to make git diff write to stdout?
  • git upstream is gone after removing remote branch
  • 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?

  • Turning off the pager in git for the stash command only
  • Git: can we compare two staged-version of the same files?
  • How to move git commits from master to a different existing branch
  • can commits by TWO people have the same hash?
  • Git http - securely remember credentials
  • git - Still cannot push to non-bare repo after setting receive.denycurrentbranch=ignore
  • 3 Solutions collect form web for “How to maintain long running git branches”

    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.

    Git Baby is a git and github fan, let's start git clone.