Git: Changes keep getting lost due to seemingly random merges

后端 未结 2 855
野趣味
野趣味 2021-02-03 10:57

I have a feeling this will be an obvious answer, but I can\'t seem to work it out.

What appears to happen is that I commit/push some changes to the server and everything

相关标签:
2条回答
  • 2021-02-03 11:37

    In your example, someone is merging f36908d (the first parent; their HEAD at the time of the merge) and 8def6e9 (the second parent; probably the tip of the origin branch at the time of the merge) to produce 326c8fd0.

    If the merge commit (326c8fd0) is missing significant pieces of content with respect to either of its parents (f36908d and 8def6e9; you say it is missing pieces of the latter), then whoever create the merge commit is probably executing the merge in an inappropriate fashion.

    This person may be using the ours merge strategy (merge or pull with -s ours/--strategy=ours), the ours option to the default recursive merge strategy (merge or pull with -X ours/--strategy-option=ours), or they may just be making bad decisions when manually resolving the merge conflicts.

    The ours strategy completely ignores any content changes made in the history all parents but the first. You can usually identify this type of merge because the merge commit and its first parent (i.e. their changes) will have identical trees (i.e. git diff f36908d 326c8fd0 would show no differences).

    The ours merge strategy option will also ignore changes from the history of the second parent (i.e. your changes), but only those that conflict with changes made in the history of the first parent (i.e. their changes). In this case, some changes from the second parent may make it into the result, but others may be dropped entirely.

    The other likely alternative is that they are just making bad decisions while resolving conflicts generated during a default merge.

    Either way, someone will probably have to talk to the user that did the merge to find out exactly what they did, and why they did it so that a policy can be devised to prevent the problem in the future.


    To recover, you might redo the merge yourself and them merge the result into the current tip of the history:

    git checkout -b remerge f36908d
    git merge 8def6e9
    # resolve conflicts and commit
    git checkout develop
    git merge remerge
    # maybe resolve more conflicts
    
    # eventually: git branch -d remerge
    

    Or, if you are okay with rewriting history:

    git checkout -b remerge f36908d
    git merge 8def6e9
    # resolve conflicts and commit
    git rebase --onto remerge 326c8fd0 develop
    # maybe more conflicts to resolve at each rebased commit
    
    0 讨论(0)
  • 2021-02-03 11:49

    If you are losing commits, ensure that neither of you is using --force or a force flag on your gui to get rid of rejected. Take a look at the explanation of the DAG.

    http://progit.org/book

    hope this helps.

    0 讨论(0)
提交回复
热议问题