Multiple uncommited changes in pull request after "resolved conflicts"/"merge"

Question

Hello,

My team recently moved to git from SVN and we are having a strange problem with the workflow. In our development cycle we use Bitbucket and TortoiseGit and a Standard Git Flow like strategy.

The main problem is that, after we resolve the conflicts (the way Bitbucket suggests), in the differences page of the commits we see changes that were not committed and pushed.

The way we resolve the conflicts is:

1- in TortoiseGit we switch to the branch we develop (the feature branch) (henceforth known as: the current branch)

2- we make a pull from the branch we want to merge into (aka: the destination branch)

3- open the "edit conflicts" window/tab

4- pick which version to use for that particular file

5- save file and mark that conflict as resolved

6- commit the modifications we made in the current branch; by default TortoiseGit selects all the changes/modified files we have on the repository even though we don't want to commit all the development configs and dependencies we have on our environment, so we deselect everything and pick only the files on which the conflict appeared.

7- we push the commit to the remote repository (Bitbucket)

8- spend hours to reverts files manually that should not have been committed :(  and pray that we did not loose any code in the process (from the source branch or the destination branch)

As a side-note to step 6:

In the commit window (where we pick what files to commit) we see stuff modified even though we did not modify them in the current branch, but I think they were modified in the destination branch. Something tells me this is where we mess-up, maybe Git thinks that if we don't commit them we say that our version of the file (the older than what we have on the destination branch) is the correct one.

Also, if we select to commit a file that was not modified in the current branch but was on the destination branch, MOST OF THE TIME it looks like it recommits the file from the destination branch into the current branch. We could try to manually look at what was updated in the destination branch and select them for commit, but usually there are hundred of flies modified each time, so this approach defeats the point of using a Version Control System and having separate branches with automatic merges.

Can someone explain why this is happening and how to avoid this situation (maybe a different way to resolve the conflicts). Maybe I misunderstood what Git or Bitbucket is doing behind the scenes (I personally would expect only stuff that I committed to appear in the pull request but maybe the local version gets committed without us explicitly selecting it)

Thank you,

Signed: A confused developer

nerrierr · Answer

Hello,

It is as you say.

The situation appeared due to the way that GIT and the client (TortoiseGit) handles the reverse merge and the fact that we had different understanding/expectation of what is happening.

From what I understand, after the conflict is resolved GIT expects that you will commit everything that you want to keep in the branch (including auto-merged files that only keep all the changes from the destination branch). If you do not commit stuff after the conflict is resolved, it thinks that you want to keep what you have in the "source" branch; even thou that is the "old" version, so it will effectively revert the changes that other developers did on the destination branch. The fact that the client allows you to unselect those files in the commit was what caused the confusion. We were unselecting everything and only committing the files that were conflicted due to the fear of committing stuff by accident (not all developers keep their local work-area/directory clean).

It is good that the client allows you to select what you want to commit since we often have local changes that we do not want to commit (for testing purposes or configs). What is not good is the fact that it usually automatically selects all modification to files already tracked (... but that's another story).

We tested our workflow with the command line (CLI/Terminal) and it appears to be working fine (because it basically stages all the auto-marged files and commits everything without you explicitly saying that you want to commit those files).

In my personal opinion this revert is a bigger overall problem with GIT itself, since it is doing stuff behind the scenes and making weird assumptions about what you want to do. I doubt many users are aware of this behavior (since it's not something you would expect) and might stumble into similar problems. That being said, after you understand what is going on (the merge between branches histories and pushing the result) you can implement workarounds for the issues.

As a solution to our problem, I advised my team to use the command line terminal OR clone new clean repository and commit everything when resolving conflicts (I know it's not the most efficient work process, but since using it we did not have any more problems).

Thank you,

Baskar Annamalai · Answer

Hello there,

Thanks for the detail explanation, were you able to reproduce the same on CLI/Terminal? I'm suspecting that this could be related to the GIT Client misbehaving. Could you resolve the conflict using the CLI/Terminal and if there is changes on Bitbucket Server?

Regards,