在github上的fork中跟踪上游的最佳实践

Question

简介：在您希望维护一组本地更改的情况下，处理上游存储库的长时间跟踪的最佳实践是什么？

我想在github上保持与上游最新的分支，但仍然允许清楚地跟踪fork的特有变化。 （对于此讨论，假设upstream指向主项目存储库，而该origin指的是我的存储库的fork）

想象一下，我有类似这样的东西，当上游/主人在E时我分叉了一个存储库。

Upstream:
A-B-C-D-E-F


Fork:    
A-B-C-D-E ----- P ------T
         \-L-M-/ \-Q-R-/

在分配存储库后，我创建了两个功能分支（LM和QR）来添加我需要的新功能，并将它们合并回我的origin / master。 所以现在我的分支机构有了上游不存在的改进。

我发现上游有几个有趣的修复，所以我想重新与上游同步。 基于我发现的大多数引用（ git hub fork ），推荐的方法是将upstream / master合并到你的origin / master中并继续前进。 所以我会发出如下命令：

git checkout master
git fetch upstream
git git merge upstream/master
git push

然后我最终会得到如下所示的存储库：

Upstream:
A-B-C-D-E-F


Fork:    
A-B-C-D-E ----- P ------T-F'
         \-L-M-/ \-Q-R-/

虽然我看到了一些问题。

1. 我实际上并没有在我的仓库中提交F，我有F'，它具有相同的内容，但是有一个不同的哈希。 所以我不能轻易引用两个存储库之间的提交，并知道我有一个更改。 （当考虑到上游可能有多个更改并且拥有已经合并的自己的一组功能分支时，它会变得更加复杂）

2. 当我继续前进并继续这样做时，我越来越难以知道我的存储库中的更改超出了上游的更改。 例如，我可以向上游提交一些这些更改，同时继续添加我自己的改进。 经过几次迭代后，任何查看我的存储库的人如何知道它与上游的区别？ （是否有一个git命令来查找这些更改？）

3. 与＃2类似，有人会如何在上游找到修复程序并检查我的fork是否包含修复程序？

我想问题的根源是我无法保证我的存储库在任何给定点与上游“同步”，因为代码和散列不一样。 那么我该如何准确地跟踪变化并避免疯狂地试图让事情保持同步？

注意：我曾考虑使用rebase来保持我的存储库在上游的重新定位，但这有一组完全不同的问题。 例如，如果有人通过子模块，分支等引用我的存储库，那么历史记录重写将破坏它们的引用。 另外，我不认为我的分支历史可以在rebase中存活，所以我不能完整地查看我所做的所有功能分支以及相关的历史记录。

别人怎么处理这个？ 我应该研究哪些最佳实践？

---

更新：

根据Seth的反馈，我创建了一组测试存储库，以显示我所谈论的内容以及它如何按照他说的方式工作。

存储库是：

• 上游的
• 叉子

当局部变化时，他们应该更清楚地显示上游的合并情况。

Answer 1

你的假设不正确。 您在文本示例中说过您将运行git merge命令。 如果你真的是这个意思，而不是git cherry-pick （并且为了记录，git-merge是这种情况下的最佳实践）那么你不会在你的分支中获得F`，你得到F.也许是一张图片：

在获取之后但在合并之前，您的repos看起来像这样：

Upstream:
A-B-C-D-E-F  [master]


Fork:    /-F                  [upstream/master]
A-B-C-D-E ----- P ------T     [master]
         \-L-M-/ \-Q-R-/      [Other branches]

合并后，您的仓库将如下所示：

Fork:    /-F-------------\    [upstream/master]
A-B-C-D-E ----- P ------T-U   [master]
         \-L-M-/ \-Q-R-/      [Other branches]

您的仓库中的新提交“U”将是合并提交，就像提交“P”和“T”一样。

如你在例子中所示， git cherry-pick会创建“F”。 不要那样做。 git rebase有时可以支持rebasing分支git rebase -p但它并不总是有效。 而且，这是重写公共历史，这是一个坏主意。

我有一个关于git最佳实践的文档： 经常提交，后期完善，发布一次您可能特别想要调查工作流程部分以获得进一步的灵感。