title: Tortoise Git - lost commits after a pull resulted in conflicts
body: <p>This SO question perfectly describes our situation:
  <a href="https://stackoverflow.com/questions/20077616/what-is-the-right-way-to-commit-push-when-there-are-conflicts-in-gittortoise-gi">What is the right way to commit/push when there are conflicts in Git or TortoiseGit?</a></p>
  
  <p>There is no answer (atleast not one that is accepted) on the above question.</p>
  
  <p>This seems to be one of the solutions:
  <a href="https://stackoverflow.com/a/12171221/172396">https://stackoverflow.com/a/12171221/172396</a></p>
  
  <p>However I think that's an overkill. I just lost a commit to my colleagues. Git being a distributed VCS, I thought it would be okay if we advise colleagues to make local commits and then push to a central repo once or twice a day. Most of the time, they are working on separate modules, and won't cause a conflict. On occasional conflicts, I thought we can always resolve locally and then make another local commit and remote push.</p>
  
  <p>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.</p>
  
  <p>Is this expected? How are we supposed to work locally and then re-sync once in a while.
  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.</p>