1

情况是我们有一个为大众构建的产品，我们在 GIT 存储库中拥有它（我们称之为upstream）。我们的一个客户想要一个定制版本的产品，所以我们将它分叉并保存在一个 diff GIT 存储库中（让我们称之为origin）。

想法是在自己的客户定制开发方向上引领 origin repo，同时继续接收来自上游的更新。

我已将上游作为远程添加到我正在开发它的本地存储库中，并且我知道我可以从上游提取更新，合并它们或任何看起来不错的东西，但我想听听做过或做过的人它是为了使工作流程顺畅并避免任何可能的陷阱？

编辑： fetch-merge 工作流程会像两个 repos 中的相同更改一样处理吗？就像工作已经开始在 fork 和我在 origin 本身修复的一些东西一样，但我也需要在上游进行相同的修复。那么我是否应该在上游再次提交以修复该问题，并且 git 可以在下次合并它们以更新 fork 时检测到相似性，或者我应该将该修复作为单独的提交提交，即使它符合我所做的工作提交？我更关心的是如何让这个过程以最小的摩擦进行。

另一个问题：在小改动上使用cherry-pick 似乎是个好主意。想法？

4

2 回答 2

1

由于未来的合并问题，尽可能避免挑选樱桃（如“如何在 git 中合并特定提交”中所述）

樱桃从一个分支选择提交到另一个分支基本上涉及生成一个补丁，然后应用它，因此也会以这种方式丢失历史。

这种提交 ID 的更改破坏了 git 的合并功能

尝试隔离您知道需要在他们自己的提交中应用到其他 repo 的更改，以便仅应用这些更改。
然后 a git fetch，后跟rebase分支的 a ，是在分支历史记录中包含来自上游的提交的最佳方式。
这类似于“ git 工作流程和变基与合并问题”中描述的工作流程（参见更新部分）。

于 2012-08-01T10:26:17.123 回答
0

为避免挑剔，您可能需要仔细查看系统的设计/架构。它被分成功能模块越多，使用插件机制等，就越容易向两个分支添加功能和更新。

如果系统没有整齐地划分为模块，那么在合并过程中没有 git 工作流可以解决您的问题，并且合并将变得越来越复杂。

于 2012-08-01T10:56:04.633 回答