3

I have a development branch called "feature/multientity" that was branched off from master. After my work was done I merged the feature branch into a staging branch called "staging-multientity-merge" that was also branched off from master. There were merge conflicts which I resolved and then I merged the staging branch back into master. However, all of the commits that I made in "feature/multientity" were not merged. Only one commit, the one where I fixed the merge conflicts, was merged. So now, even though the code is up-to-date, any future merges from "feature/multientity" to master will have merge conflicts because none of the commits were carried over. Has anyone run into this issue before? I am using SourceTree as my versioning tool.

Suryatej Mukkamalla
  • 131
  • 3
  • Are you using the so-called "squash merge" technique? If so, note that a squash merge is not a merge at all, it's just a single ordinary commit. – torek Jun 24 '16 at 23:15
  • I did not squash merge. It was a simple merge of the feature branch into the staging branch. – Suryatej Mukkamalla Jun 25 '16 at 02:19

2 Answers2

2

I ran into your described issue and I am using SourceTree as visualisation tool. I solved the issue by resetting to state before merge, and merge properly. I apparently tried merging both branches to master where I should have merged feature branch into staging branch first. This can happen if branch names are non-trivial.

You can try following steps to merge your feature branch changes to the staging branch before merging all changes to master:

  1. Checkout feature/multientity

  2. Reset feature/multientity to state before merge commit, use e.g. git log --stat to find the commit hash before merge commit. Use git reset --hard commit_hash_here

  3. Repeat for staging branch, reset staging-multientity-merge to state before merge commit

  4. Now git checkout staging-multientity-merge first and use command git merge feature/multientity here only after checking out the staging branch. This will bring changes from feature/multientity to staging branch.

  5. Use git status to monitor the status of merging, and fix any merge conflicts. Commit using git commit -m "Your merge conflict resolution message here." Now your staging branch is ready to merge to master.

  6. Next, use git checkout master, this is something I forgot, and complete the work using git merge staging-multientity-merge. Use Create a new commit even if fast-forward is possible option in SourceTree commit view, (lower left corner), this will enable that multiple branches do not point in a single commit in SourceTree commit view. Using no-fast-forward here does create a visually more pleasing outlook in the SourceTree commit history view in my opinion.

Using this approach, resetting the branches may force you to force push changes to remote repository, but it is not needed if you did not push unsuccessful merge to remote yet.

While I was having this problem of unsuccessful merge, I had difficult time interpreting the SourceTree tool visuals about each branch. The colours are arbitrary and just there to help you visualise a parent-child relation of a commit. See Atlassian Community answer about what SourceTree tool branch colour visuals represent to learn more about SourceTree.

Erkka Mutanen
  • 639
  • 1
  • 10
  • 14
  • Additionally, the author's issue may arise if another colleague has pushed a git operation called revert in your target branch AND you have merged earlier to target branch. A git merge revert will cause your history to be reverted in this case. You can fix this by reverting the revert. Here's an excellent letter which describes an [issue with merge revert](https://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.html). Also you can see how to redo a reverted merge [here](https://stackoverflow.com/questions/1078146/re-doing-a-reverted-merge-in-git) – Erkka Mutanen Nov 12 '17 at 14:44
  • 1
    Such a shame this wasn't marked as the right answer! Hugely helped me so thank you @erkka – sidonaldson Feb 16 '23 at 18:37
0

Doesnt make sense. When you look at the merge commit into staging-multientity-merge, do you see your changes from feature/multientity? If so, they are in there. If not, did you mess up during your merge conflict resolution and not include them or not complete the merge with a git add/rm and then git commit? Same for the merge commit into master.

David Neiss
  • 8,161
  • 2
  • 20
  • 21
  • The changes are there, but they are all condensed into the one merge commit. The commit history of each individual commit is not there. My process was as follows: 1) Checkout "staging-multientity-merge" locally. 2) Pull "feature/multientity" into the local branch and resolve all merge conflicts. 3) Commit the resolution. 4) Push local branch to remote branch and create pull request to merge into master. – Suryatej Mukkamalla Jun 24 '16 at 20:21
  • Ah, ok, so you were looking for your commit messages to be in the merge commit? Because it doesn't do that by default. Add in a --log flag to get that, see https://git-scm.com/docs/git-merge. – David Neiss Jun 24 '16 at 22:42
  • No. After I merged into the staging branch, I did "git log" and the only new commit I saw was the merge commit. All of the commits from the "feature/multientity" branch were not part of the branch history. – Suryatej Mukkamalla Jun 25 '16 at 02:00
  • ok, so you aren't understanding merging then. There are already many good writeups already out there. For instance, read https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging – David Neiss Jun 25 '16 at 15:13
  • In your example, one the development branch has been merged to master, master branch will still hold a reference to the commits made in the development branch. That is what I am missing when I did my merge. – Suryatej Mukkamalla Jun 25 '16 at 16:56