Git 显示我添加了另一个人的更改
Git shows I added another person's changes
我自己和一个同事在同一个分支工作（不是一直都在，但现在）。他和我大约在同一时间做出了承诺，他推送了他的更改。
我通过 Github 桌面进行了推送，我惊讶地发现有两个提交分配给了我自己：我的原始提交和 https://github.com/company/repository 的“合并分支 'xyz'”进入xyz”，这是我没想到的。看来我把他的改动合并到分支了。
我的期望是，因为我没有进行强制推送，所以我无法设置分支以包含我的更改而没有同事的更改。从我从 Github 桌面日志中看到的，它看起来像是在推送之前完成了拉取（因此合并）。但是，查看历史记录，在我看来，分支设置为首先包含我的更改，没有我的同事更改，然后我将这些更改合并进去，这正是我认为如果不强制推送是不可能的。
对于历史记录，我的首选 'state' 是仅显示我合并到分支中的更改，而不是我对同事所做的更改。完成此操作的唯一方法是使用我的更改创建一个新的命名分支，提交并推送，切换回原始分支，然后从新命名的分支合并吗？
出于某种原因，我认为这基本上可以在不经过所有这些无关步骤的情况下发生。我错了吗？有没有更好的方法来完成这个？
谢谢！
如果两个人在同一个分支上工作，那么在自然过程中几乎不可避免地每个人都会提交，并且一个人会在另一个人之前推送。于是我们首先会出现这种情况：
A -- B -- C --| <-- master G -- H <-- branch as seen by them
\ /
D -- E -- F -- |
\
I -- J <-- branch as seen by us
然后，他们push的时候，这个情况：
A -- B -- C --| <-- master
\
D -- E -- F -- G -- H <-- branch on the remote
\
I -- J <-- branch as seen by us
如果你现在拉，你有 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（我认为那是 good，因为它保留了历史真相）但它不影响你的 以任何方式分支；你的分支只是一个人在前进。
我自己和一个同事在同一个分支工作（不是一直都在，但现在）。他和我大约在同一时间做出了承诺，他推送了他的更改。
我通过 Github 桌面进行了推送，我惊讶地发现有两个提交分配给了我自己：我的原始提交和 https://github.com/company/repository 的“合并分支 'xyz'”进入xyz”，这是我没想到的。看来我把他的改动合并到分支了。
我的期望是，因为我没有进行强制推送，所以我无法设置分支以包含我的更改而没有同事的更改。从我从 Github 桌面日志中看到的，它看起来像是在推送之前完成了拉取（因此合并）。但是，查看历史记录，在我看来，分支设置为首先包含我的更改，没有我的同事更改，然后我将这些更改合并进去，这正是我认为如果不强制推送是不可能的。
对于历史记录，我的首选 'state' 是仅显示我合并到分支中的更改，而不是我对同事所做的更改。完成此操作的唯一方法是使用我的更改创建一个新的命名分支，提交并推送，切换回原始分支，然后从新命名的分支合并吗？
出于某种原因，我认为这基本上可以在不经过所有这些无关步骤的情况下发生。我错了吗？有没有更好的方法来完成这个？
谢谢！
如果两个人在同一个分支上工作，那么在自然过程中几乎不可避免地每个人都会提交，并且一个人会在另一个人之前推送。于是我们首先会出现这种情况：
A -- B -- C --| <-- master G -- H <-- branch as seen by them
\ /
D -- E -- F -- |
\
I -- J <-- branch as seen by us
然后，他们push的时候，这个情况：
A -- B -- C --| <-- master
\
D -- E -- F -- G -- H <-- branch on the remote
\
I -- J <-- branch as seen by us
如果你现在拉，你有 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（我认为那是 good，因为它保留了历史真相）但它不影响你的 以任何方式分支；你的分支只是一个人在前进。