Tortoise Git - lost commits after a pull resulted in conflicts

前端 未结 2 1917
悲哀的现实
悲哀的现实 2021-01-16 04:26

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

2条回答
  •  刺人心
    刺人心 (楼主)
    2021-01-16 04:55

    For everyone's benefit, this is the strategy that I have resorted to that seems to work well for us.

    1. If a Git pull, results in a conflict, resolve the conflict locally.
    2. Ensure there are no remaining files that are conflicted.
    3. Do a Git pull again.
    4. Goto Step 2 if you again get a conflict.

    Basically you try to resove conflicts and do a Git pull and keep on doing this until a Git pull completes successfully with no conflicts (effectively meaning your commit head now is updated to the remote commit head).

    A change of mindset is needed when addressing conflicts if you are coming from a SVN background. In SVN, a merge conflict during an update does not abort the SVN update process. SVN client would still update your local copy to the latest remote revision. Only individual files would be left in conflicted state that you can resolve (and commit back if needed).

    So a conflict still means all local files that were not conflicted are up--to-date with the remote repo after an update.

    In Git, a conflict during pull simply terminates/aborts the update process. So if the remote repo had 10 commits that need to be pulled, and you get a conflict when Git was pulling (and merging) the 3rd of these commits, effectively the process is aborted. 8 of the remote commits are NOT in your local repo (note the remote commit that caused a conflict also isn't merged successfully, so its 8 commits that are not synced locally and not 7).

    You resolve conflicts and keep doing a git pull until successful thus preventing you from overwriting other commits. To provide a bit more details from what I have understood about git, a push without resolving the conflict would cause the remote branch's commit head to be relocated incorrectly. e.g. suppose you need to pull 4 revisions from a Git repo:

    A - B - C - D
                |- commit head
    

    Now suppose you get a conflict while pulling and merging Revision B. If you do a push now to remote (without resolving the conflicts and doing a git pull until successful), the remote repo now looks like this:

    A - B - C - D
        |- E - commit head
    

    So effectively although commits C/D exist remotely, they won't be a part of your build based on the branch's commit head. If you follow @CupCake's advice and push the remaining files, commits C/D become a part of commit E sort of. So that doesn't impact your correctness of the build. But if you don't push those files after conflict which you don't changed but Git was showing as modified (because you did not resolve the conflict and completed a successful git pull), then effectievly you are leading to lost commits.

提交回复
热议问题