如何防止合并的更改显示为 'changes to be committed'
How to prevent merged changes from appearing as 'changes to be committed'
第二个开发人员和我一起在一个功能分支上工作。我们想通过在 master 分支中所做的更改来测试此功能。通常我可能会使用 git rebase master，但由于一些原因这不会起作用。
- 更改已推送到远程并与其他开发人员共享。
- 与 master 存在合并冲突，这会使 rebase 变得复杂且有风险。
所以我想将 master 合并到我的功能分支中以获取更改。但是，当我合并时，对 master 所做的特定更改显示为 'changes to be committed'。我想象当我提出拉取请求以将这些更改放入 master 时，由于其他人的更改的噪音，它会使审查更改变得混乱且难以遵循。
在使用 git merge 时，使用来自 master 的更改更新功能分支的正确方法是什么，而不会使拉取请求因不相关的更改和重复提交而混乱？
我四处寻找，找不到这个问题的好答案，因为大多数人都推荐变基。 This 似乎是最接近的，但它接受的答案有-1票，其他人实际上没有回答这个问题。
您将两种不同的事情混为一谈：一方面是分阶段更改（要提交的更改），另一方面是拉取请求更改集。
拉取请求不是一个 git 概念，因此它们如何计算变更集取决于实现它们的主机服务。如果拉取请求以合理的方式计算其更改集，则不应出现您描述的问题。在 git 级别，当发出从 branch 到 master 的拉取请求时，您希望将更改计算为 master..branch - 这不包括 master 合并的提交出于完全相同的原因，它排除了 branch 创建时已经存在的 master 提交。我 相信 github 处理得当。
但是关于您问题的另一面：假设您不希望更改显示为 "changes to check in" - 或者这与拉取请求审查的外观密切相关 - 是误入歧途。为了使合并提交正确合并来自 master 的更改，它们必须在索引中表示，这使得它们 "changes to be committed".
解决这个问题的唯一方法是根本不提交合并。有些人建议这样做（出于与有些人建议不断进行变基操作的原因类似的原因）。我不同意该建议（出于与我不同意持续变基操作的建议类似的原因）。
如果您确实决定不保留合并，您可以使用 git rerere 减轻（但不是消除）该决定的一些不利方面，这有助于重新应用可能存在的任何冲突解决方案当你放弃合并时被扔掉。
第二个开发人员和我一起在一个功能分支上工作。我们想通过在 master 分支中所做的更改来测试此功能。通常我可能会使用 git rebase master，但由于一些原因这不会起作用。
- 更改已推送到远程并与其他开发人员共享。
- 与 master 存在合并冲突，这会使 rebase 变得复杂且有风险。
所以我想将 master 合并到我的功能分支中以获取更改。但是，当我合并时，对 master 所做的特定更改显示为 'changes to be committed'。我想象当我提出拉取请求以将这些更改放入 master 时，由于其他人的更改的噪音，它会使审查更改变得混乱且难以遵循。
在使用 git merge 时，使用来自 master 的更改更新功能分支的正确方法是什么，而不会使拉取请求因不相关的更改和重复提交而混乱？
我四处寻找，找不到这个问题的好答案，因为大多数人都推荐变基。 This 似乎是最接近的，但它接受的答案有-1票，其他人实际上没有回答这个问题。
您将两种不同的事情混为一谈：一方面是分阶段更改（要提交的更改），另一方面是拉取请求更改集。
拉取请求不是一个 git 概念，因此它们如何计算变更集取决于实现它们的主机服务。如果拉取请求以合理的方式计算其更改集，则不应出现您描述的问题。在 git 级别，当发出从 branch 到 master 的拉取请求时，您希望将更改计算为 master..branch - 这不包括 master 合并的提交出于完全相同的原因，它排除了 branch 创建时已经存在的 master 提交。我 相信 github 处理得当。
但是关于您问题的另一面：假设您不希望更改显示为 "changes to check in" - 或者这与拉取请求审查的外观密切相关 - 是误入歧途。为了使合并提交正确合并来自 master 的更改，它们必须在索引中表示，这使得它们 "changes to be committed".
解决这个问题的唯一方法是根本不提交合并。有些人建议这样做（出于与有些人建议不断进行变基操作的原因类似的原因）。我不同意该建议（出于与我不同意持续变基操作的建议类似的原因）。
如果您确实决定不保留合并，您可以使用 git rerere 减轻（但不是消除）该决定的一些不利方面，这有助于重新应用可能存在的任何冲突解决方案当你放弃合并时被扔掉。