【发布时间】：2014-11-04 23:06:08
【问题描述】：
在进行开源开发时，在对主题分支进行任何更改的同时跟踪上游一段时间是很正常的。将上游带回来时，我注意到的一件事是创建了合并提交。如果我随后创建拉取请求，则此合并提交最终会成为 PR 的一部分。
我的问题是，这样做有什么害处吗？我读到有些人觉得它们没用，但我喜欢它们充当我上次与上游同步时的时间戳。是否有一种公认的做法来跟踪上游和引入合并提交。
【问题讨论】：
标签： git
【发布时间】：2014-11-04 23:06:08
【问题描述】：
当将上游带回来时，会创建一个合并提交。
这就是为什么最好：
-
git rebase master（在更新的远程跟踪分支之上重新设置您的分支） -
git push -f（强制将您的分支推送到您的 GitHub 分支：现有 PR 将相应更新）
如果满足以下条件，效果很好：
- 您的 PR 在自己的分支中完成
- 没有其他人在积极使用您的分支
【讨论】：
-
虽然我可以从删除额外提交的角度理解上述内容，但我仍然不确定我是否看到了删除它的意义，而不是希望修改提交流。也许您可以详细说明为什么这是必要的？
-
@McDonnellDean 是的：stackoverflow.com/a/23285782/6309 和 stackoverflow.com/a/14681796/6309。 GitHub 中的 PR 被强制推送：它们将为您更新。这个想法是将你的 PR 保留在它自己的分支中，始终基于更新的远程跟踪分支的顶部，以确保最终合并（在原始 repo 中完成）将是一个微不足道的合并。