情况是我们有一个我们为群众建立的产品，我们将它放在GIT仓库（我们称之为upstream）。我们的一位客户需要该产品的定制版本，因此我们将其分叉并保存在差异GIT仓库中（我们称之为origin）。
想法是引导原始回购在其自身的发展方向上进行客户定制，并继续从上游接收更新。
我已将上游作为远程添加到我正在开发它的本地仓库中，并且我知道我可以从上游获取更新，合并它们或任何看起来不错但我希望听到已经完成的人或者这样做是为了使工作流程顺利进行以及避免任何可能的陷阱？
编辑：fetch-merge工作流处理是否会像两个repos中的相同更改一样？就像工作已经开始在fork和一些我修复原产地的东西，但我也需要在上游同样的修复。所以，我应该在上游进行另一次提交以修复它，并且git可以在下次合并它们时更新fork来检测相似性，或者我应该将该修复作为单独的提交提交，即使它有资格进行我的工作提交吗？我更关心的是如何使这个过程以最小的摩擦力工作。
另一个问题：对于小变化，使用cherry-pick似乎是一个好主意。想法？
答案 0 :(得分：1)
如果可能，请避免挑选，因为将来会出现合并问题（如“How to merge a specific commit in git”中所述）
从一个分支到另一个分支的提交基本上涉及生成补丁，然后应用它，从而也以这种方式丢失历史。这种更改提交ID会破坏git的合并功能
尝试隔离您知道需要在自己的提交中应用于其他仓库的更改，以便仅应用这些更改。
然后，git fetch，然后是您的分支的rebase，是在您的分支历史记录中包含上游提交的最佳方式。
这类似于“git workflow and rebase vs merge questions”中描述的工作流程（请参阅更新部分）。
答案 1 :(得分：0)
为避免采摘樱桃，您可能需要仔细查看系统的设计/架构。它越多被分成功能模块，使用插件机制等，可能更容易为两个分支添加功能和更新。
如果系统没有整齐地拆分成模块，那么在合并期间没有git工作流可以解决您的问题，合并将变得越来越复杂。