Merging git branch A into branch B once again after the first merge has been reverted

My situation is presented below.

              o---o---o issue-2 
             /         \
o---o---o---o---M---R---o develop
         \     /
          o---o---F issue-1

There was some work on issue-1. After review, it was merged into develop (commit M). Unfortunately, it was soon discovered that there were some serious errors present. For the sake of other issues the merge commit was reverted (commit R). Later, other issues (like issue-2) were also merged into develop. The code on the original branch was fixed (commit F).

The problem is – how to merge issue-1 into develop now? The simple merge would keep the effect of revert commit R and only apply changes that are not already in develop branch (commit F), not all of them.

  • Failed merge in EGit
  • git-p4 and pulling from other repos
  • Why am I getting tree conflicts in Subversion?
  • Git - merging into master always produces same conflicts even though fixed last time
  • Cocoapods project.pbxproj merge conflicts
  • Is it possible to replace git merge algorithm?
  • git segfaults on merge - submodule conflict
  • How to configure GIT merge logic?
  • One Solution collect form web for “Merging git branch A into branch B once again after the first merge has been reverted”

    There are a few options:

    1. revert the revert
      • pros: this is the approach recommended by the Git documentation, and it’s easy to do
      • cons: uglies the history, which makes it a little more difficult for people to understand how the code evolved over time (e.g., git blame will show the revert of the revert instead of the individual commits on the issue-1 branch)
    2. rebase the reverted branch and merge that
      • pros: git blame and other history digging tools make it easier to understand the code history
      • cons: looking at the history can be a bit confusing (why are there two seemingly identical sets of commits in the history? did someone botch a rebase?)
    3. edit history: redo your develop branch to remove both commit M and commit R
      • pros: cleanest end result
      • cons:
        • DANGEROUS if your repository is shared, unless your users are good with Git and you have communicated the plan to everyone
        • difficult to do because Git doesn’t have an easy history editing tool:
          • rebase doesn’t make it easy to edit (or edit out) merges, and the --preserve-merges option doesn’t work with interactive rebasing so you’ll end up flattening the issue-2 commits into develop
          • filter-branch is difficult to use

    In general the approach I recommend is to revert the revert. I suggest following these detailed steps:

    1. Check out the original bad branch:
      git checkout issue-1
    2. Merge in the latest commits from the parent branch:
      git merge --no-ff develop
    3. Revert the revert (where R is the SHA1 ID of the revert commit):
      git revert R
    4. Fix the flaws in the branch. (You’ve already done this in commit F; for others’ sake I’ll assume you need to make an additional fix.)
    5. TEST TEST TEST
    6. Switch back to the parent branch:
      git checkout develop
    7. Merge in the repaired branch:
      git merge --no-ff issue-1

    The resulting graph should look like this:

                  o---o---o issue-2 
                 /         \
    o---o---o---o---M---R---o-------------o develop
             \     /         \           /
              o---o---F-------o---RR---F2 issue-1
    

    It’s not pretty, but people should be able to figure out what’s going on.

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