为合并请求准备分支

要处理某个功能，我从development产生一个新的feature分支，对其进行处理并向development提交合并请求（MR）。在我的工作feature，development分支可以改变很多。为合并请求准备分支

为了避免提交我的MR合并之前，我合并最新development冲突为feature，和我的feature提交与其他吨的提交从development混合，使得提交历史相当难看，我估计很难过审查。

我想到了这一点，准备当MR：
而是合并development到feature的，从最新development创建新的分支feature-mr，然后合并或摘樱桃从feature到feature-mr，最后提交MR的feature-mr到development 。

我不知道这种常见问题是否有一种常见的做法。

来源

2015-04-07 kiruwka

您要找的是git rebase development。

您的资料库看起来像这样，其中feature落后于development。

A - B - C - D - E [development] 
    \ 
     F - G - H [feature]

git rebase development将在开发之上重播每个功能补丁。有点像樱桃采摘F，G和H.你结束了这一点。

A - B - C - D - E [development] 
    \   \ 
     F - G - H F1 - G1 - H1 [feature]

F，G和H最终会被垃圾收集。这需要几周的时间，所以你可以回到他们身上，如果底线变得混乱了。

您可以使用git pull --rebase origin development一步更新您的存储库并重新署名feature。这将执行git fetch origin，然后git rebase origin/development而不是git merge origin/development。请注意，您的本地development分支不会更新，您必须这样做。如果这让您感到困惑，请忽略它，并继续您的正常工作流程替换git merge development与git rebase development。

请注意，由于提交ID更改，如果您已推入feature，则会出现问题。你将不得不git push --force和其他人在feature工作将很难拉。

来源

2015-04-07 08:53:45 Schwern

谢谢你的回答。如果我定期“合并”拉开发展，然后在'feature'上开发'git rebase development'，你的方法是否可行？原因是，我工作的地方每个人都在合并，而且我不习惯重新设定/解决分配冲突的问题。 – kiruwka

@kiruwka是的，发展如何得到更新并不重要。让我编辑答案，以澄清我的意思是“拉开发展”。 – Schwern

已接受。我试过了：1）首先通过'git pull'更新我的本地'development'，然后2）'git rebase development'功能。第二步确实出现了重新布局冲突，我必须逐个解决冲突，并为每个冲突提交应用'git rebase --continue'。尽管如此，它并没有太多问题，并且最终似乎工作正常。然而，我没有提交MR之后这样做，但希望这将工作得很好：） – kiruwka

为合并请求准备分支

回答

相关问题