用于本地提交，上游提交和部署的Git工作流

Question

我知道有很多关于git工作流的帖子，但我找不到我正在寻找的内容：有关以下工作流程的最佳做法的建议：

我有一个通过git部署的Web应用程序。应用程序开发人员通过公共git仓库发布更新。我也有自己需要应用的更改。处理这个问题的最佳方法是什么？

我一直在做什么：我创建了一个从上游克隆的本地部署仓库。这是通过gitolite提供的，所以它是一个简单的回购。我有一个这个仓库的克隆，我在其上应用更改，并将它们推回到部署仓库。当更改发布到上游存储库时，我已使用推荐的命令将它们合并到此克隆中：

git fetch && git pull --rebase

然后我推送到部署仓库。问题是我开始在我改变的任何文件上遇到大量的合并冲突。在rebase期间，同一个文件会给我带来很多冲突。我正在寻找一种可以或多或少自动化的方法，但我不太了解问题是什么。

任何git大师都可以提供一些建议吗？如果有任何需要澄清，请告诉我。谢谢。

Answer 1

我不想知道并记住蹩脚，丑陋，愚蠢，“原始”的Git-jargoon，所以我会以“需要的行动”的形式写食谱，将其翻译成命令我离开你的任务

<强>制备

将您当前的工作流程发送到垃圾箱

操作

• 您必须拥有一个回购 两个分支（供应商和拥有者）。供应商分支链接到上游的远程仓库，您的分支是单个位置，您可以在其中存储自己的更改。必须从供应商创建分支自己，为了获得两个分支中所有文件的共同父项，必须使用您的更改修补Own中的文件
• 通过从远程更新供应商分支并与之后的Own分支合并（从供应商更改合并到自己）与上游同步执行

只有在合并阶段双方（您和上游）文件更改时才会发生冲突

Answer 2

如果你从git pull中删除了--rebase，那么你当前的工作流程会很好。然后pull将执行合并（默认值）而不是rebase，并且您将减少冲突。当然，总会出现git无法自行解决冲突的情况，因此该流程无法完全自动化。

问题在于，rebase需要执行许多步骤，返回整个历史记录并解决您在上游之上所做的每个更改。这对于您的方案来说是不必要的，甚至适得其反，因为它无法判断您的更改何时相对于上游的更改。合并将更好地工作，因为它们只需要一步而且不必在历史中返回很远（仅限于之前的合并）。

如果你在进行合并时仍然遇到比你想要的更多的冲突，你将不得不找到减少修订和上游之间差异的方法（你可以在合并后轻松检查git diff） ），或将您的更改移动到上游不经常修改的位置（或上游不存在的位置）。