我曾在本地分支工作过，也曾将更改推到远程。我想还原对该分支的更改并在其上执行其他操作，但我不想完全丢失所做的工作。我考虑在本地创建一个新分支并将旧分支复制到那里，然后我可以还原更改并继续在旧分支上工作。有比这更好的办法吗？
bvjveswy1#
git checkout old_branch git branch new_branch
这将为您提供一个新分支“new_branch”，其状态与“old_branch”相同。此命令可与以下命令组合使用：
git checkout -b new_branch old_branch
sgtfey8w2#
参见第二部分（自Git 2.23，Q3 2019起）：第一个月在Git 2.15（Q4 2017）中，"git branch"学习了"-c/-C"通过复制现有分支来创建新分支。参见Ævar Arnfjörð Bjarmason ( avar )（2017年6月18日）。参见commit 52d59cc、commit 5463caa（2017年6月18日）和Sahil Dua ( sahildua2305 )。（由Junio C Hamano -- gitster --合并到commit 3b48045，2017年10月3日）
git branch
-c/-C
avar
sahildua2305
gitster
branch
--copy
-c
--move
-m
添加--copy分支及其reflog和配置的功能，这使用与--move（-m）选项相同的底层机制，只是reflog和配置是复制而不是移动的。这对于例如将主题分支复制到新版本是有用的，例如在将work主题提交到列表之后将work复制到work-2，同时保留所有跟踪信息和与分支一起的其它配置，并且不像--move那样保留其它已经提交的分支以供参考。注意：复制分支时，您将保留在当前分支上。作为Junio C Hamano explains，这个新特性的最初实现是修改HEAD，这是不好的：当通过复制恰好是当前分支的分支A来创建新分支B时，它还更新HEAD以指向新分支。之所以这样做，可能是因为"git branch -c A B"在"git branch -m A B"上搭载了它的实现，这与通常的预期不符。如果我坐在一把蓝色的椅子上，有人来把它重新漆成红色，我会接受坐在一把现在是红色的椅子上（我也可以站着，因为不再有我最喜欢的蓝色椅子）。但是，如果有人按照我坐的蓝椅子的样式创造了一把新的红椅子，我不希望被踢下蓝椅子，最后坐在新的红椅子上。第二部分：使用git 2.23（Q3 2019），无需使用git分支或old confusing git checkout：你有git switch。
work
work-2
A
B
HEAD
git branch -c A B
git branch -m A B
git checkout
git switch
git switch -c newBranch oldBranch
在Git 2.40（2023年第一季度）中，'git branch -c'（man）更加健壮，可以检测到无操作情况。参见Rubén Justo ( rjusto )的commit cfbd173（2022年11月17日）。（由Junio C Hamano -- gitster --合并至commit 963f8d3，2022年12月19日）
git branch -c
rjusto
签署人：鲁本·胡斯托签署人：泰勒·布劳由于52d59cc（"branch：添加一个--copy（-c）选项来搭配--move（-m）"，2017 - 06 - 18，Git v2.15.0-rc0--merge列在batch #12中）我们可以使用"-c "（复制）选项复制一个分支来创建一个新分支，或者使用"-C "（强制复制）选项覆盖现有分支。当我们被要求将分支复制到自身时，我们考虑了空操作的可能性，以便遵循3f59481（branch：允许无操作，2011年11月25日，Git v1.7.9-rc0--merge）（分支：允许无操作"分支-M <current-branch>头"，2011 - 11 - 25）。为了检查这一点，在52d59cc中，我们比较了用户提供的分支名称、源（如果省略HEAD）和目的地，如果匹配，则认为是no-op。由于ae5a6c3（checkout：已实施，2009年1月17日，Git v1.6.2-rc0--merge）（检查：为第N个最后分支实现"@{- N} "快捷方式名称，2009 - 01 - 17），可以使用@{-1}等快捷方式指定分支。这允许以下用法：
<current-branch>
checkout
$ git checkout -b test $ git checkout - $ git branch -C test test # no-op $ git branch -C test @{-1} # oops $ git branch -C @{-1} test # oops
由于我们使用用户提供的分支名称来进行比较，如果其中一个分支是使用快捷方式提供的，则不会有匹配项，并且将调用git_config_copy_section()。这将复制该分支的配置，随着这一进程的进行，第二次调用将产生配置的四个副本，依此类推。让我们使用解释过的分支名称来进行比较。重命名操作不受影响。
git_config_copy_section()
holgip5t3#
git branch copyOfMyBranch MyBranch
这就避免了 checkout 一个分支的耗时和不必要的行为。回想一下 checkout 修改“工作树”，如果它很大或包含大文件（例如图像或视频），这可能需要很长时间。
unftdfkk4#
鉴于您要求更好的方式选择：复制分支的一个潜在缺陷是，如果你想合并到同一个父分支，或者把修改从副本重新引入到原始分支，你必须注意git的快进行为。例如，如果你已经恢复了'original'分支中的一些提交，但是现在你想重新引入你恢复到原始分支的更改，你不能简单地将复制的分支合并到父分支，因为git认为那些提交已经存在（即使它们稍后被恢复）。也许cherry-pick [commit-range]可以在这种情况下工作&不关心现有的散列 * 耸耸肩 *在我看来，这样做会更好。1.从当前分支HEAD git branch [archive-branch-name]创建新分支1.使用git log查找要回滚到的提交1.运行git reset --head [commit-hash-from-#2]
cherry-pick [commit-range]
git branch [archive-branch-name]
git log
git reset --head [commit-hash-from-#2]
git push -f origin
或者更简单的是，你可以完全取消分支，只恢复你想要恢复的提交，如果你需要的话，还有revert the revert later
r7knjye25#
checkout 到你想要复制的分支。然后一旦你在那个分支上运行：第一个月
5条答案
按热度按时间bvjveswy1#
这将为您提供一个新分支“new_branch”，其状态与“old_branch”相同。
此命令可与以下命令组合使用：
sgtfey8w2#
参见第二部分（自Git 2.23，Q3 2019起）：第一个月
在Git 2.15（Q4 2017）中，"
git branch"学习了"-c/-C"通过复制现有分支来创建新分支。参见Ævar Arnfjörð Bjarmason (
avar)（2017年6月18日）。参见commit 52d59cc、commit 5463caa（2017年6月18日）和Sahil Dua (
sahildua2305)。（由Junio C Hamano --
gitster--合并到commit 3b48045，2017年10月3日）branch：添加一个--copy（-c）选项以与--move（-m）搭配使用添加
--copy分支及其reflog和配置的功能，这使用与--move（-m）选项相同的底层机制，只是reflog和配置是复制而不是移动的。这对于例如将主题分支复制到新版本是有用的，例如在将
work主题提交到列表之后将work复制到work-2，同时保留所有跟踪信息和与分支一起的其它配置，并且不像--move那样保留其它已经提交的分支以供参考。注意：复制分支时，您将保留在当前分支上。
作为Junio C Hamano explains，这个新特性的最初实现是修改HEAD，这是不好的：
当通过复制恰好是当前分支的分支
A来创建新分支B时，它还更新HEAD以指向新分支。之所以这样做，可能是因为"
git branch -c A B"在"git branch -m A B"上搭载了它的实现，这与通常的预期不符。
如果我坐在一把蓝色的椅子上，有人来把它重新漆成红色，我会接受坐在一把现在是红色的椅子上（我也可以站着，因为不再有我最喜欢的蓝色椅子）。
但是，如果有人按照我坐的蓝椅子的样式创造了一把新的红椅子，我不希望被踢下蓝椅子，最后坐在新的红椅子上。
第二部分：使用git 2.23（Q3 2019），无需使用git分支或old confusing
git checkout：你有git switch。在Git 2.40（2023年第一季度）中，'
git branch -c'（man）更加健壮，可以检测到无操作情况。参见Rubén Justo (
rjusto)的commit cfbd173（2022年11月17日）。（由Junio C Hamano --
gitster--合并至commit 963f8d3，2022年12月19日）branch：通过@{-1}将分支强制复制到自身是空操作签署人：鲁本·胡斯托
签署人：泰勒·布劳
由于52d59cc（"
branch：添加一个--copy（-c）选项来搭配--move（-m）"，2017 - 06 - 18，Git v2.15.0-rc0--merge列在batch #12中）我们可以使用"-c "（复制）选项复制一个分支来创建一个新分支，或者使用"-C "（强制复制）选项覆盖现有分支。当我们被要求将分支复制到自身时，我们考虑了空操作的可能性，以便遵循3f59481（
branch：允许无操作，2011年11月25日，Git v1.7.9-rc0--merge）（分支：允许无操作"分支-M<current-branch>头"，2011 - 11 - 25）。为了检查这一点，在52d59cc中，我们比较了用户提供的分支名称、源（如果省略HEAD）和目的地，如果匹配，则认为是no-op。
由于ae5a6c3（
checkout：已实施，2009年1月17日，Git v1.6.2-rc0--merge）（检查：为第N个最后分支实现"@{- N} "快捷方式名称，2009 - 01 - 17），可以使用@{-1}等快捷方式指定分支。这允许以下用法：
由于我们使用用户提供的分支名称来进行比较，如果其中一个分支是使用快捷方式提供的，则不会有匹配项，并且将调用
git_config_copy_section()。这将复制该分支的配置，随着这一进程的进行，第二次调用将产生配置的四个副本，依此类推。
让我们使用解释过的分支名称来进行比较。
重命名操作不受影响。
holgip5t3#
这就避免了 checkout 一个分支的耗时和不必要的行为。回想一下 checkout 修改“工作树”，如果它很大或包含大文件（例如图像或视频），这可能需要很长时间。
unftdfkk4#
鉴于您要求更好的方式选择：
复制分支的一个潜在缺陷是，如果你想合并到同一个父分支，或者把修改从副本重新引入到原始分支，你必须注意git的快进行为。
例如，如果你已经恢复了'original'分支中的一些提交，但是现在你想重新引入你恢复到原始分支的更改，你不能简单地将复制的分支合并到父分支，因为git认为那些提交已经存在（即使它们稍后被恢复）。
也许
cherry-pick [commit-range]可以在这种情况下工作&不关心现有的散列 * 耸耸肩 *在我看来，这样做会更好。
1.从当前分支HEAD
git branch [archive-branch-name]创建新分支1.使用
git log查找要回滚到的提交1.运行
git reset --head [commit-hash-from-#2]git push -f origin请注意，您从“原始”分支开始，并且在执行这些步骤的过程中不更改分支。
或者更简单的是，你可以完全取消分支，只恢复你想要恢复的提交，如果你需要的话，还有revert the revert later
r7knjye25#
checkout 到你想要复制的分支。然后一旦你在那个分支上运行：第一个月