时间戳

首页 > 解决方案 > 如何将分支与部分重新设置并强制推送的 master 合并？

git - 如何将分支与部分重新设置并强制推送的 master 合并？

问题描述

最初，我需要从master恢复一些提交，包括合并的 pull request。我们称之为“不需要的重构”。

但这些变化在未来是需要的。

我根据master的当前状态创建了一个新的分支开发，以便在那里进行这些更改。

  1. 我决定将master硬重置为 pull request 合并的父提交（它是 repo 的稳定状态）：

    git reset --hard ad23b887

  2. 然后，选择其他不是“不需要的重构”的提交：

    git cherry-pick

现在我想做一个强制推送命令，它应该覆盖原始/主分支历史。

将来，当它经过 100% 测试时，我需要将“不需要的重构”从开发中合并回master 。但是，如果事实上它们有不同的历史（因为樱桃挑选和重置 HEAD），我应该如何合并这两个分支？

通过重置 HEAD 并只挑选我在我的情况下需要的那些，这是恢复提交的正确方法吗？

Ps 我的团队由两个人组成，我认为进行此类操作没有任何问题。

标签： gittfs

解决方案

让我们形象化它。

最初，我需要从 master 恢复一些提交，包括合并的 pull request ......

A - B - C --------- M [master]
     \             /
      F - G - H - I

我根据 master 的当前状态创建了一个新的分支开发，以便在那里进行这些更改。

                      [develop]
A - B - C --------- M [master]
     \             /
      F - G - H - I

我决定将 master 硬重置为 pull request 合并的父提交（它是 repo 的稳定状态）：git reset --hard ad23b887

假设 ad23b887 是提交 B。

A - B [master]
    |\
    | C ----------- M [develop]
     \             /
      F - G - H - I

那是同一张图，只是稍微移动了一点，以便我们可以与 master 一起工作。

然后，选择其他不是“不需要的重构”的提交：git cherry-pick

假设这是 G 和 I。

A - B - G1 - I1 [master]
    |\
    | C ----------- M [develop]
     \             /
      F - G - H - I

现在我想做一个强制推送命令，它应该覆盖原始/主分支历史。

是的，但使用git push --force-with-lease. 它更安全。我把它别名为repush。

将来，当它经过 100% 测试时，我需要将“不需要的重构”从开发中合并回 master。但是，如果事实上它们有不同的历史（因为樱桃挑选和重置 HEAD），我应该如何合并这两个分支？

Rebase 在 master 之上开发。这将在 master 之上重放开发者的提交。合并将消失。你挑选的现在多余的提交也将如此，因为现在开发已经从 master 那里获得了这些更改。

A - B - G1 - I1 [master]
    |\
    | C ----------- M [develop]
     \             /
      F - G - H - I 

$ git checkout develop
$ git rebase master

A - B - G1 - I1 [master]
              \
               C - F - H [develop]

现在您可以通过正常的 PR 流程合并开发。

A - B - G1 - I1 -------- M1 [master]
              \         /
               C - F - H

通过重置 HEAD 并只挑选我在我的情况下需要的那些，这是恢复提交的正确方法吗？

让我们回到你采摘樱桃之前。

避免像开发这样的通用分支。给它一个与你正在做的事情相关的名字。一个不错的选择是在问题跟踪器中使用 ID，这会鼓励每个分支都有问题。

A - B [master]
    |\
    | C ----------- M [issue/#1234]
     \             /
      F - G - H - I

我建议永远不要直接提交 master ，而是始终使用功能分支。这样可以确保每个更改都经过审查、QA 等 PR 流程。这意味着 master 始终可以稳定地工作。

为此，创建一个新分支，仅用于合并樱桃精选。

$ git checkout -b issue/#abcd
$ git cherry-pick G I

      G1 - I1 [issue/#abcd]
     /
A - B [master]
    |\
    | C ----------- M [issue/#1234]
     \             /
      F - G - H - I

他们通过正常的 PR 流程将其合并。

      G1 - I1
     /       \
A - B ------- N [master]
    |\
    | C ----------- M [issue/#1234]
     \             /
      F - G - H - I

现在在 master 之上 rebase issue/#1234。

      G1 - I1
     /       \
A - B ------- N [master]
               \
                C - F - H [issue/#1234]

并通过正常的 PR 流程合并 issue/#1234。

      G1 - I1
     /       \
A - B ------- N --------- M1 [master]
               \         /
                C - F - H

历史上的那些颠簸被称为“功能泡沫”，它们就是你想看到的。它们有助于保持历史简单易懂，掌握稳定。

推荐阅读