Git 良好实践，在两者都在发展时保持 fork 项目与其源来源保持同步

Question

语境
我是Next Right Now的主要作者这是一个开源“样板”，包含使用 Next.js 框架构建 Web 应用程序的几个“预设”。每个预设都带有内置功能，旨在进行 fork ，以便其他人可以基于它构建他们的应用程序。每个预设都位于自己的 git 分支中，例如:

https://github.com/UnlyEd/next-right-now/tree/v2-mst-aptd-at-lcz-sty

https://github.com/UnlyEd/next-right-now/tree/v2-mst-aptd-gcms-lcz-sty

我正在研究 NRN 并使其定期发展。
但是，我还 fork 了一个可用的 NRN 预设，并从中制作了我自己的专有应用程序。
定义
为了避免术语误解，这里有一些定义。

Fork:一个 NRN 预设 fork 到另一个项目中，无论是开源的还是专有的。

来源:用于生成 Fork 的 NRN 预设。 (例如，假设 Source git 分支是 https://github.com/UnlyEd/next-right-now/tree/v2-mst-aptd-at-lcz-sty ，这是我用来创建我的 Fork 的 NRN 预设)

问题
这种做事方式的问题在于我不确定如何使“Fork”与 NRN 样板预设保持同步。两者都以自己的方式发展。此外，NRN 不是一个框架而是一个样板，它旨在被覆盖以自定义基本代码，这最终会导致 Fork 和 Source 之间的许多冲突。
到目前为止我一直在做什么
为了让我的 Fork 与 Source 上的最新变化保持同步，我基本上 rebase我自己在 Source git 历史记录之上的工作。 (例如: git rebase NRN-v2-mst-aptd-at-lcz-sty)
这有以下优点(优点):

它使历史保持干净且易于理解/比较。通过比较它们的历史记录，我可以很容易地知道哪个是我从源同步的最新提交。所有在 Fork 中完成的工作都完成了 顶部 在 Source 中做了什么。

git 树分为两个不同的部分，源提交树和 Fork 提交树。

我可以通过使用 git rebase 使我的 Fork 保持最新状态，然后 push --force 将来自 Source 的新更改同步到 Fork 中。覆盖 Remote 。

但也有一些缺点(缺点):

Fork只有一个分支的时候，处理两个分支之间的同步并没有那么复杂，但是一旦有多个分支就会变得很乱，因为它重写了所有分支的git历史，当有分支时就变得相当复杂Fork 中其他“功能”分支的持续工作。首先，我需要重新设置 Fork:master 的基础，然后使用 Fork:master 重新设置每个分支的基础。如果我以错误的方式做它会弄乱整棵树(我犯了一次错误，并且到处都使用--force 进行 rebase 是两个痛苦的小时)

它在 Fork:master 上使用 --force分支，恕我直言，这不是很好，如果处理不当，可能会导致很多麻烦。我对我正在做的事情有点熟悉，但是如果团队中有更多人，这将不可行。

总的来说，我对自己有能力不把事情搞砸的能力没有信心。

感觉它不适合团队，它只是因为我正在独自工作，恕我直言。

当它发生冲突时，解决起来可能会很痛苦，而且我碰巧犯了好几次错误。

git 历史是不可信的，我的 Fork 工作分支在与 Source 同步时重写了它们的提交历史，并且所有 GitHub 评论都失去了用处，因为它们不再与任何提交匹配。

使用 rebase，我最终不得不删除我的整个工作分支并通过挑选我在 Fork 中完成的所有提交从源重新创建它，因为历史不再匹配，我需要一个干净的开始。这是在我以错误的方式重新定位而犯了一些错误之后发生的。
我在找什么
我目前的方式工作正常，只要我是独奏，只要我很好地了解我的 git 分支，只要我不通过重新定位和 push --force 错误的方式来搞砸。不过，这并不能让我满意。
我正在寻找一种更好的方法，该方法可用于团队，并且我可以将其用作“官方推荐”的方式来保持 Fork 与其 NRN 源同步。
备择方案
我想过 cherry-pick -ing 从 Source 提交到我的 Fork，但我不确定它是否是更好的选择，因为它会将 Source 和 Fork 提交混合在一起(两者之间不再分离)。这最终会导致在比较两棵树并找出哪些提交已经被挑选出来而哪些没有被挑选时遇到困难。此外，它并不能保护我免于忘记挑选一个提交并在数周后遇到麻烦，这可能会导致使用 --force 重写历史记录以将丢失的提交包含在正确的位置。
我没有考虑任何其他选择，因为我不知道。

因此，我正在为我的特定用例寻找“最佳实践”。我很确定 Git 有一些很棒的方法来处理这个问题，这是我所不知道的。

Answer 1

我看到几个选项:
merge
正如一些人所建议的，使用原始(根)存储库上的新提交来“更新” fork 的最简单选项是 merge 。这将确保:

您可以轻松地从根存储库 library/framework/获得最新的修复

您在 fork 中的提交和在 root 中的提交完全分开

我会 不鼓励 rebase 对于这个特殊问题。正如您所提到的，您的 fork 存储库的历史记录将被有效修改，这可能会影响在那里工作的其他开发人员/功能分支(甚至在单一开发人员存储库上)等...
如果你必须在相反的方向 merge 补丁，fork -> root，你会 git cherry-pick git submodule另一种选择是将基础库/框架作为 git submodule在 fork 里。在标准形式中，git 子模块只是指向另一个存储库+提交的指针。历史是分开的，因为它们确实是两个不同的存储库。
要在基础上集成新更改，您只需重新指向 git submodule到这个新的提交。
一个重要的注意事项；只有当您的 fork 存储库不涉及根存储库的文件时，这才会有效。 git subtree我对 git subtree 不够熟悉能够判断。但你也应该看看，因为这听起来像是另一个可行的解决方案