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

小结：对于要维护一组本地更改的上游存储库，处理长期跟踪的最佳实践是什么

我想让github上的fork与上游保持最新，但仍然允许清晰地跟踪fork特有的更改。（在本讨论中，假设

上游

指向主项目存储库，而

来源

指向存储库的我的分支）

想象一下，当上游/master在E

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


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

在分叉respository之后，我创建了两个特性分支（L-M和Q-R），以添加我需要的新特性，并将它们合并回我的origin/master。所以现在我的分支有了上游不存在的改进

我发现upstream有几个有趣的补丁，所以我想重新与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-/

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]

不过，我认为这有几个问题

我的repo中实际上没有commit F，我有F'，它有相同的内容，但有不同的散列。因此，我无法轻松引用两个存储库之间的提交，并且知道我有一个更改。（当考虑到上游可能有不止一个变更，并且有自己的一组已合并的功能分支时，情况变得更加复杂）

当我继续前进并继续这样做时，我越来越难以知道我的存储库中除了上游之外还有哪些变化。例如，我可以在继续添加自己的改进的同时，将其中一些更改提交回上游。经过几次迭代之后，查看我的存储库的人如何知道它与上游的区别？（是否有git命令来查找这些更改？）

与#2类似，如何在上游找到修复程序并检查我的fork是否包含该修复程序

我想问题的根源在于，我无法保证我的存储库在任何给定点都与上游“同步”，因为代码和哈希不相同。那么，我该如何准确地跟踪变化，避免自己在试图保持同步时发疯呢

注意：我曾考虑过使用rebase来保持我的存储库不在上游，但这有一组完全不同的问题。例如，如果有人通过子模块、分支等引用我的respository，那么历史重写将中断他们的引用。此外，我认为我的分支历史不会在重新基准后继续存在，因此我无法完整查看我创建的所有功能分支和相关历史

其他人是如何处理的？我应该研究哪些最佳实践

---

更新：

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

存储库包括：

---

它们应该更清楚地显示，当存在局部变化时，从上游合并的情况如何。

您的假设是错误的。您在文本示例中说您将运行

git merge

命令。如果你真的这么想，而不是

git cherry pick

（记录在案，git merge是这种情况下的最佳实践），那么你的分支中就不会得到F`

在提取之后合并之前，您的回购协议如下所示：

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


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

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]

合并后，您的回购将如下所示：

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


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

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

有时可以支持对分支进行重定基

git-rebase-p

，但并不总是有效。而且，这是重写公共历史，这是一个坏主意

---

我有一个关于git最佳实践的文档：您可能特别想研究工作流部分以获得进一步的灵感。

谢谢您的指点。我添加了一个示例来说明它的行为与您描述的一样。现在看起来很明显，但我忽略了合并的要点，即使用匹配的提交散列从上游引入历史。还有一个问题：如果我在我的fork上，我怎样才能轻松地找到与上游不同的所有更改，并以一种让我能够理解/看到fork有哪些功能而上游没有的方式进行更改。@Allen:

git log--graph--decoration--oneline master..upper/master

，具体取决于您正在尝试的操作，改变两者的顺序。分开的参数或将点数改为三可能会有所帮助。