将最新提交移动到带有Git的新分支


Move the most recent commit(s) to a new branch with Git

我想把我对master的最后几次承诺转移到一个新的分支，并在做出这些承诺之前将master带回。不幸的是，我的功夫还不够强，有什么帮助吗？

也就是说，我怎样才能摆脱这个困境呢？

1
master A - B - C - D - E

对此？

1
2
3
newbranch     C - D - E
             /
master A - B
相关讨论

移动到新分支

警告：此方法有效，因为您正在使用第一个命令创建一个新的分支：git branch newbranch。如果要将提交移动到现有分支，则需要在执行git reset --hard HEAD~3之前将更改合并到现有分支(请参见下面的移动到现有分支)。如果不先合并更改，则更改将丢失。

除非涉及到其他情况，否则很容易通过分支和回滚来完成。

1
2
3
4
# Note: Any changes not committed will be lost.
git branch newbranch      # Create a new branch, saving the desired commits
git reset --hard HEAD~3   # Move master back by 3 commits (GONE from master)
git checkout newbranch    # Go to the new branch that still has the desired commits

但一定要确保返回多少提交。或者，您可以不使用HEAD~3，只需提供要在主(当前)分支上"还原到"的提交(或引用，如origin/master)的哈希，例如：

1
git reset --hard a1b2c3d4

*1您只会"失去"来自主分支机构的承诺，但不要担心，您将在Newbranch中获得这些承诺！

警告：对于Git版本2.0及更高版本，如果您在原来的(master分支上更新git rebase分支，您可能需要在rebase期间明确的--no-fork-point选项，以避免丢失结转的承诺。拥有branch.autosetuprebase always集使这更可能发生。详情请参阅约翰·梅勒的回答。

移动到现有分支

如果要将提交移动到现有分支，它将如下所示：

1
2
3
4
5
git checkout existingbranch
git merge master
git checkout master
git reset --hard HEAD~3 # Go back 3 commits. You *will* lose uncommitted work.
git checkout existingbranch
相关讨论

对于那些想知道为什么它会起作用的人(就像我起初那样)：

你想回到C，把D和E移到新的分支。首先是这样的：

1
2
3
A-B-C-D-E (HEAD)
        ↑
      master

在git branch newbranch之后：

1
2
3
4
5
    newBranch
        ↓
A-B-C-D-E (HEAD)
        ↑
      master

在git reset --hard HEAD~2之后：

1
2
3
4
5
    newBranch
        ↓
A-B-C-D-E (HEAD)
    ↑
  master

由于分支只是一个指针，所以master指向最后一次提交。当您创建Newbranch时，只需为最后一次提交创建一个新指针。然后使用git reset将主指针移回两次提交。但是，由于你没有移动Newbranch，它仍然指向它最初所做的承诺。

相关讨论

一般来说。。。

在这种情况下，Sykora公开的方法是最好的选择。但有时不是最简单的方法，也不是一般的方法。对于一般方法，使用git cherry pick：

要实现OP想要的，它有两个步骤：

第1步-注意您希望从主服务器提交的newbranch

执行

1
2
git checkout master
git log

注意你在newbranch上想要的(比如3)承诺的散列。在这里我将使用：C承诺：9aa1233。D承诺：453ac3d。承诺：612ecb3。

Note: You can use the first seven characters or
the whole commit hash

第二步-把它们放在newbranch上

1
2
3
4
git checkout newbranch
git cherry-pick 612ecb3
git cherry-pick 453ac3d
git cherry-pick 9aa1233

或(在Git 1.7.2+上，使用范围)

1
2
git checkout newbranch
git cherry-pick 612ecb3~1..9aa1233

Git Cherry Pick将这三项承诺应用于Newbranch。

相关讨论

另一种方法是，只使用两个命令。同时保持当前工作树的完整性。

1
2
git checkout -b newbranch # switch to a new branch
git branch -f master HEAD~3 # make master point to some older commit

旧版本-在我了解git branch -f之前

1
2
git checkout -b newbranch # switch to a new branch
git push . +HEAD~3:master # make master point to some older commit

能够从push到.是一个很好的技巧。

相关讨论

以前的大多数答案都是危险的错误！

不要这样做：

1
2
3
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

下次运行git rebase或git pull --rebase时，这些3个提交将从newbranch中被悄悄丢弃！(见下文解释)

而是这样做：

1
2
3
git reset --keep HEAD~3
git checkout -t -b newbranch
git cherry-pick ..HEAD@{2}
  • 首先，它放弃了最近的3个承诺(--keep与--hard相似，但更安全，因为失败而不是放弃未承诺的更改)。
  • 然后它从newbranch分叉。
  • 然后，cherry选择这3个提交回newbranch。由于分支不再引用它们，因此使用git的reflog可以做到这一点：HEAD@{2}是HEAD以前用来引用2个操作的承诺，即在we 1之前。已签出newbranch和2。使用git reset放弃3次提交。

警告：reflog在默认情况下是启用的，但是如果您手动禁用了它(例如，通过使用"裸"Git存储库)，则在运行git reset --keep HEAD~3之后将无法获得3次提交。

另一种不依赖于反射的方法是：

1
2
3
4
5
6
7
# newbranch will omit the 3 most recent commits.
git checkout -b newbranch HEAD~3
git branch --set-upstream-to=oldbranch
# Cherry-picks the extra commits from oldbranch.
git cherry-pick ..oldbranch
# Discards the 3 most recent commits from oldbranch.
git branch --force oldbranch oldbranch~3

(如果你愿意，你可以写@{-1}——以前签出的分支——而不是oldbranch)。

技术说明

为什么git rebase会在第一个示例之后放弃3个提交？这是因为没有参数的git rebase默认情况下启用--fork-point选项，该选项使用本地reflog尝试对被强制推送的上游分支保持强大。

假设您在包含提交m1、m2、m3时分支了origin/master，然后自己进行了三次提交：

1
2
3
M1--M2--M3  <-- origin/master
         \
          T1--T2--T3  <-- topic

但随后有人强迫原点/主数据删除m2来重写历史：

1
2
3
M1--M3'  <-- origin/master
 \
  M2--M3--T1--T2--T3  <-- topic

使用您的本地reflog，git rebase可以看到您来自一个早期的起源/主分支的化身，因此m2和m3提交实际上不是主题分支的一部分。因此，它合理地假设，由于m2已从上游分支中删除，因此在主题分支重新调整后，您不再希望它出现在主题分支中：

1
2
3
M1--M3'  <-- origin/master
     \
      T1'--T2'--T3'  <-- topic (rebased)

这种行为是有意义的，而且通常在重新平衡时是正确的。

所以以下命令失败的原因是：

1
2
3
git branch -t newbranch
git reset --hard HEAD~3
git checkout newbranch

是因为他们让反射处于错误的状态。Git将newbranch视为在包含3个提交的修订中分叉上游分支，然后reset --hard重写上游的历史以删除提交，因此下次运行git rebase时，它会像从上游删除的任何其他提交一样丢弃它们。

但在这个特定的案例中，我们希望这3个承诺被视为主题分支的一部分。为了实现这一点，我们需要在早期的版本(不包括3个提交)中划分上游。这就是我建议的解决方案所做的，因此它们都将reflog保持在正确的状态。

有关详细信息，请参见git-rebase和git-merge基本文档中的--fork-point的定义。

相关讨论

使用git stash的更简单的解决方案

如果：

  • 您的主要目的是回滚master，以及
  • 您希望保留文件更改，但不特别关心错误提交消息，以及
  • 你还没推，还有
  • 您希望这很容易，并且不复杂，包括临时分支、提交哈希和其他令人头疼的问题。

那么，下面就简单多了(从有三个错误承诺的master分支开始)：

1
2
3
4
git reset HEAD~3
git stash
git checkout newbranch
git stash pop

这是做什么的，按行号

  • 撤消对master的最后三次提交(及其消息)，但保留所有工作文件的完整性。
  • 隐藏所有工作文件更改，使master工作树完全等于head~3状态
  • 切换到现有分支newbranch。
  • 将隐藏的更改应用于您的工作目录并清除隐藏

    • 现在您可以像平时那样使用git add和git commit。所有新的承诺都将添加到newbranch中。

    这不能做什么

    • 它不会在你的树上留下杂乱的临时树枝
    • 它不会保留错误的提交和提交消息，因此您需要向这个新提交添加一个新的提交消息。

    目标

    OP表示，目标是"在提交之前将master恢复到原来的状态"，而不会丢失更改，而这个解决方案会做到这一点。

    我每周至少做一次这样的事情，因为我不小心把新的承诺交给了master，而不是develop。通常我只有一个提交回滚，在这种情况下，在第1行上使用git reset HEAD^是只回滚一个提交的更简单的方法。

    如果你把大师的改变推到上游，不要这样做。

    其他人可能已经改变了。如果你只是在重写你的本地大师，那么当它被推到上游时没有任何影响，但是将一个重写的历史推给合作者会导致头痛。

    相关讨论

    从技术角度来说，这不会"移动"它们，但它具有相同的效果：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    A--B--C  (branch-foo)
     \    ^-- I wanted them here!
      \
       D--E--F--G  (branch-bar)
          ^--^--^-- Opps wrong branch!

    While on branch-bar:
    $ git reset --hard D # remember the SHAs for E, F, G (or E and G for a range)

    A--B--C  (branch-foo)
     \
      \
       D-(E--F--G) detached
       ^-- (branch-bar)

    Switch to branch-foo
    $ git cherry-pick E..G

    A--B--C--E'--F'--G' (branch-foo)
     \   E--F--G detached (This can be ignored)
      \ /
       D--H--I (branch-bar)

    Now you won't need to worry about the detached branch because it is basically
    like they are in the trash can waiting for the day it gets garbage collected.
    Eventually some time in the far future it will look like:

    A--B--C--E'--F'--G'--L--M--N--... (branch-foo)
     \
      \
       D--H--I--J--K--.... (branch-bar)
    相关讨论

    要在不重写历史记录的情况下执行此操作(例如，如果您已经推送了提交)：

    1
    2
    3
    4
    git checkout master
    git revert <commitID(s)>
    git checkout -b new-branch
    git cherry-pick <commitID(s)>

    然后可以不用力地推两个分支！

    相关讨论

    就在这种情况下：

    1
    2
    3
    Branch one: A B C D E F     J   L M  
                           \ (Merge)
    Branch two:             G I   K     N

    我表演：

    1
    2
    3
    git branch newbranch
    git reset --hard HEAD~8
    git checkout newbranch

    我原以为我会是负责人，但现在我是…

    为了确保降落在历史上的正确位置，更容易处理提交的混乱问题。

    1
    2
    3
    git branch newbranch
    git reset --hard #########
    git checkout newbranch

    1)创建一个新分支，将所有更改移动到新分支。

    1
    git checkout -b new_branch

    2)然后回到旧的分支。

    1
    git checkout master

    3)做吉特钢筋

    1
    git rebase -i <short-hash-of-B-commit>

    4)然后打开的编辑器包含最后3个提交信息。

    1
    2
    3
    4
    5
    ...
    pick <C's hash> C
    pick <D's hash> D
    pick <E's hash> E
    ...

    5)将所有3项承诺中的pick改为drop。然后保存并关闭编辑器。

    1
    2
    3
    4
    5
    ...
    drop <C's hash> C
    drop <D's hash> D
    drop <E's hash> E
    ...

    6)现在从当前分支中删除最后3个提交(master)。现在用力推树枝，在树枝名称前加上+号。

    1
    git push origin +master

    你可以这样做，这只是我使用的3个简单步骤。

    1)创建新的分支，在其中提交最近的更新。

    git branch

    2)查找新分支上提交的最近提交ID。

    git log

    3)复制该提交ID注意，最新的提交列表在顶部。所以你可以找到你的承诺。你也可以通过信息找到这个。

    git cherry-pick d34bcef232f6c...

    您还可以提供一些范围的提交ID。

    git cherry-pick d34bcef...86d2aec

    现在你的工作完成了。如果您选择了正确的ID和正确的分支，那么您将成功。所以在这样做之前要小心。否则会出现另一个问题。

    现在你可以推你的代码了

    git push