CODEWITHSUNDEEP
gitatlassian-sourcetree
Suryatej Mukkamalla
Suryatej Mukkamalla

Reputation: 131

All commits lost when merging development branch back to master

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.

Upvotes: 3

Views: 1718

Answers (2)

Erkka Mutanen
Erkka Mutanen

Reputation: 727

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.

Upvotes: 2

David Neiss
David Neiss

Reputation: 8237

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.

Upvotes: 0

Related Questions