为合并请求准备分支

Question

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

为了避免合并冲突，我在提交 MR 之前将最新的 development 合并到 feature 中，并且我在 feature 上的提交与来自 development 的大量其他提交混合在一起, 使提交历史非常丑陋，我想也更难审查。

我想到了这个，当准备好 MR 时：
不要将 development 合并到 feature，而是从最新的 development 创建新分支 feature-mr，然后从 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 最终将被垃圾回收。这需要数周时间，因此如果 rebase 出现问题，您可以返回给他们。

您可以使用 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 工作的人将很难完成。

为合并请求准备分支

prepare branch for merge request

git

git-branch