问题描述
我自己和一位同事在同一个分支上工作（不是一直都在，但目前是）。他和我几乎在同一时间做出了承诺，并推动了他的更改。
我通过 Github Desktop 进行推送，我惊讶地发现有两个提交分配给我自己：我的原始提交和“将 https://github.com/company/repository 的分支 'xyz' 合并到 xyz”，这是我没有的'期待。看起来我把他的更改合并到了分支中。
我的期望是，由于我没有进行强制推送，因此我无法将分支设置为在没有同事更改的情况下包含我的更改。从我从 Github 桌面日志中可以看到，它看起来像是在推送之前完成了拉取（因此合并）。但是，查看历史记录，在我看来，分支设置为首先包含我的更改，而没有我的同事更改，然后我将这些更改合并到其中，这正是我认为不进行强制推送是不可能的。>
我对历史记录的首选“状态”是仅显示合并到分支中的更改，而不是我对同事进行的更改。完成此操作的唯一方法是使用我的更改创建一个新命名的分支，提交并推送，切换回原始分支，然后从新命名的分支合并？
出于某种原因，我认为这基本上会发生，而无需经历所有这些无关紧要的步骤。我错了吗？有没有更好的方法来实现这一点？
谢谢！
解决方法
如果两个人在同一个分支上工作，那么在事情的自然过程中几乎不可避免地每个人都会提交，一个人会先于另一个人推送。因此，我们将首先遇到这种情况：
A -- B -- C --| <-- master G -- H <-- branch as seen by them
\ /
D -- E -- F -- |
\
I -- J <-- branch as seen by us
然后，当他们推送时，这种情况：
A -- B -- C --| <-- master
\
D -- E -- F -- G -- H <-- branch on the remote
\
I -- J <-- branch as seen by us
如果你现在 pull，你有 I 和 J 但远程有 G 和 H。除非你采取特殊措施，Git 默认会自动在你的本地创建一个合并提交来协调这个差异：
A -- B -- C --| <-- master
\
D -- E -- F -- G -- H
\ \
I -- J -- M <-- branch as seen by us
... 其中 M 是合并提交。
这完全正常。谁先推送，另一个将与合并提交协调。当然，当你推送时，合并提交会被推送，所以我们得到了一个链，在分支的生命周期中，发散和合并、发散和合并的平行四边形。
如果您不喜欢合并提交，则可以在拉取时说 --rebase。在这种情况下，传入的新提交会放在第一位，而您的本地新提交会放在第二位：
A -- B -- C --| <-- master
\
D -- E -- F -- G -- H -- I' -- J' <-- branch as seen by us
\
I -- J
提交 I 和 J 被复制，使 I' 和 J' 看起来像它们，但附加到 H 处分支的传入版本的末尾。
这种 rebase 方法是一种非常标准的方法，即使您有本地提交，也可以使您的分支版本“赶上”。但这并不总是可行的，并且当 Git 拒绝这样做时会导致混乱的情况。
更标准的方法是：不要那样做。一个公共分支应该是一个没有人直接工作的地方；应该没有其他分支是共同的。你在一个功能分支上工作，他们在一个不同功能分支上工作，现在他们只是保持完全独立，每个分支都在自己的时间合并到主分支（这里称为master，虽然这个名字没有什么特别之处）。很可能仍然有一个合并提交代表每个合并到 master（我认为这是好的，因为它保留了历史真相）但它不会影响您的分支以任何方式；你的分支只是一个人前进。