Tortoise Git - lost commits after a pull resulted in conflicts

Question

This SO question perfectly describes our situation: What is the right way to commit/push when there are conflicts in Git or TortoiseGit?

There is no answer (atleast

Answer 1

I'm going to address your questions line by line:

On occasional conflicts, I thought we can always resolve locally and then make another local commit and remote push.

Yes, that's correct.

Now a colleague committed locally and was trying to push resulting in a conflict. She pulled, resolved conflicts and then ONLY pushed her changed files. The remote repo had another commit saying merge branch with some files that is effectively undoing my commits earlier. Is this expected?

Yes, it's expected (i.e. I'm not surprised), though that doesn't mean that what your coworker did was correct. Your coworker basically threw away all the work you did previously with that mege commit. I shall explain.

When git detects conflicts that it can't figure out how to auto-resolve during an attempted merge, it aborts the merge midway, leaving un-conflicted files added to your staging area, and leaving conflicted files with conflict markers un-staged in your working copy.

For example, this is what a merge that results in conflicts looks like from the command line:

git status

On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:

        modified:   hello.txt

Unmerged paths:
  (use "git add ..." to mark resolution)

        both modified:      foo.txt

Notice that git has automatically staged hello.txt to be committed, because it doesn't have any conflicts. I haven't used TortoiseGit in over 1.5+ years, but if my memory serves me correctly, staged files are represented in TortoiseGit with checked-checkboxes, which means you want to commit those files.

Un-checking those automatically-staged checkboxes is incorrect, in this case. It basically means that you don't want to commit those file changes that you've just merged in from the other branch (or in your case, from the upstream remote/origin). It's essentially throwing away the work that was done on those files.

The correct way to merge, in this case, would be to resolve the conflicted files, and then add them to the staging area to be committed, along with all the other file changes that are already there, even if you were not originally responsible for those changes.

How are we supposed to work locally and then re-sync once in a while.

That's up to how you and your team want to organize your workflow.

If I have committed locally, and a subsequent pull results in a conflict, how do I ensure I merge correctly so I don't undo previous commits on the remote repo.

Unless you have a good reason not to, as I've already said, you usually want to commit all the files, even if you weren't originally reponsible for the changes to them. Not doing so essentially means that you don't actually want to keep those changes.