为合并请求准备分支

Question

要处理某个功能，我会从feature生成一个新的development分支，处理它并向development提交合并请求（MR）。在feature工作期间，development分支可能会发生很大变化。

为了避免合并冲突，我在提交我的MR之前将最新的development合并到feature，并且feature上的提交与来自development的大量其他提交混合在一起提交历史非常难看，我想也很难复习。

我想到了这一点，为MR准备好了：
不要将development合并到feature，而是从最新的feature-mr创建新的分支development，然后从feature合并或挑选feature-mr，最后将feature-mr的MR提交给development。

我想知道这个常见问题是否存在常见做法。

Answer 1

您正在寻找的是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最终将被垃圾收集。它需要数周时间，所以如果反叛变得混乱，你可以回到它们身上。

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

请注意，因为提交ID已更改，如果您已经推送feature，则会出现问题。您必须git push --force，而feature上任何其他工作人员都会遇到困难。