Question

免责声明：我是一个git和版本控制newb。

在工作中，我们正在考虑使用git来管理我们购买的COTS产品的自定义。我有点难以找到解决这个问题的最佳方法。

我的想法是我们将有三个烫发分支：

master（默认供应商文件）
gold（master的分支，我们添加的东西+定制的供应商文件，这是黄金来源）
发展（黄金的分支，正在开发的东西，呃！）

工作流程将类似于：

供应商补丁：分支主机，更新文件，合并回主机，rebase gold将我们的定制合并回供应商更新文件
for hotfixes（我们的代码）：分支黄金，修复代码，合并回黄金，rebase开发
用于新功能（我们的代码）：分支开发，准备好后合并，在我们发布时合并为黄金

所以在我的测试中，我大多喜欢它的工作方式，提交历史看起来很好，流程似乎没问题，但我认为我遇到的一个大问题是它需要我在rebase之后强制推送。例如：

git checkout development
git checkout -b feat-myfeature
*do my thing, commit changes*
git checkout development
git merge feat-myfeature
git push

git checkout gold
git merge development
git push

git checkout master
git checkout -b patch-xxxxx
*update the vendor files, do commits*
git checkout master
git merge patch-xxxxx

git checkout gold
git rebase master
*fix conflicts, adding back our customizations*
git add .
git rebase --continue
git push (error!)

此时git告诉我，我有一个不同的历史，我要么必须拉动和解除完全相同的事情，我只是与rebase冲突或者推力也是如此......我认为推力是会给我带来各种令我头痛的事情，我甚至都不知道，拉动力迫使我再次解决同样的冲突，这让我觉得我的计划在某个地方犯了一个错误

你们能提出改善这种流程的建议吗？

编辑：格式化

Answer 1

一旦你的分支发生分歧，你就无法推动。您可以将更改推送到服务器的唯一时间是您的分支是提前远程分支，并且可以执行简单的fast-forward合并。

要推送您的重新分支，您需要强制推送，覆盖分支的远程状态。对于正在使用你的分支的其他人来说，这会对事情造成严重破坏，所以在你做之前要警告他们。

git push -f

git尝试在rebase之后推送的错误

1 个答案: