Merging git branch A to branch B again after the first merge has been checked out
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 work on problem-1. After the review, it was merged into development (commit M). Unfortunately, it soon became clear that there were some serious mistakes. For other issues, the merge was rolled back (commit R). Later, other problems (for example, problem-2) were also merged into development. The code on the original branch has been fixed (commit F).
The problem is this: how to integrate problem-1 into development? A simple merge will preserve the effect of revert commit R and only apply changes that are not yet in the development branch (commit F), but not all of them.
source to share
There are several options:
- come back
- pros: this is the approach recommended by the Git docs and is easy to do
- minus: guesses the history, which makes it a little more difficult for people to understand how the code has evolved over time (for example,
git blame
will display bounce backs instead of individual commits on a branchissue-1
)
- reinstall the checked out branch and merge it
- pros:
git blame
and other history search tools make code history easier to understand - Cons: Viewing history can be a little confusing (why are there two seemingly identical sets of commits in history? Did someone replay the permutation?)
- pros:
- change history: redo the development branch to remove both commit
M
and commitR
- pros: cleanest end result
- minuses:
- DANGER if your repository is shared, unless your users are good with Git and you have committed the plan to everyone
- difficult to do because Git doesn't have a simple tool for editing history:
- rebase doesn't make it easy to edit (or edit) the merge , and the option
--preserve-merges
doesn't work with interactive reloading, so you'll end up ditheringissue-2
intodevelop
-
filter-branch
difficult to use
- rebase doesn't make it easy to edit (or edit) the merge , and the option
In general, the approach I recommend is to return a return value. I suggest following these detailed steps:
- Check out the original bad branch:
git checkout issue-1
- Merge recent commits with the parent branch:
git merge --no-ff develop
- Return the return (where
R
is the SHA1 identifier for committing the return):git revert R
- Fix flaws in the branch. (You already did this in commit
F
; for others, I assume you need to make an additional fix.) - TEST TEST TEST
- Switch back to the parent branch:
git checkout develop
- Merging in the recovered 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 ugly, but people need to be able to figure out what's going on.
source to share