本文介绍了git switch分支而不丢弃本地更改的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

好吧,可以说有一天我们碰巧做了一堆修改,当我们提交它们时,我们注意到我们在错误的分支上工作.

Alright, lets say one day we make happen to make a bunch of modifications and when we go to commit them we notice we were working on the wrong branch.

我们如何强制git在不放弃本地更改的情况下切换分支 .

How can we force git to switch branches without discarding local changes.

我在等待回复时可能会以幼稚的方式进行处理,但是我想知道是否存在正确的程序,因为如果我说这以前没有发生过,那我会撒谎...

I'm probably going to go about this in a naive way while I wait a reply, but I would like to know if theres a correct procedure as I'd be lying if I said this hasn't happened to me before...

  • 备份已更改的存储库
  • git reset --hard
  • git checkout right-branch
  • 还原更改
  • git commit -m "changes"
  • Backup changed repo
  • git reset --hard
  • git checkout right-branch
  • Restore changes
  • git commit -m "changes"

推荐答案

有很多不同的方法,具体取决于您走的距离以及您希望它们在哪个分支上.

There are a bunch of different ways depending on how far along you are and which branch(es) you want them on.

让我们犯一个经典错误:

Let's take a classic mistake:

$ git checkout master
... pause for coffee, etc ...
... return, edit a bunch of stuff, then: oops, wanted to be on develop

所以现在您希望将尚未提交给master的这些更改保留在develop上.

So now you want these changes, which you have not yet committed to master, to be on develop.

  1. 如果您还没有一个develop,则该方法很简单:

  1. If you don't have a develop yet, the method is trivial:

$ git checkout -b develop

这将创建一个新的develop分支,无论您身在何处现在.现在您可以提交了,新内容都在develop上.

This creates a new develop branch starting from wherever you arenow. Now you can commit and the new stuff is all on develop.

确实有一个develop.看看Git是否会让您切换而无需做任何事情:

You do have a develop. See if Git will let you switch withoutdoing anything:

$ git checkout develop

这将成功,或者抱怨.如果成功,那就太好了!只是犯罪.如果不是(error: Your local changes to the following files would be overwritten ...),您仍然还有很多选择.

This will either succeed, or complain. If it succeeds, great! Justcommit. If not (error: Your local changes to the following files would be overwritten ...), you still have lots of options.

最简单的可能是git stash(与其他所有回答者一样)打败了我点击说).运行git stash savegit stash push,或仅运行git stash,这是save/push的缩写:

The easiest is probably git stash (as all the other answer-ersthat beat me to clicking said). Run git stash save or git stash push, or just plain git stash which is short for save / push:

$ git stash

这使用以下命令提交您的代码(是的,它确实进行了一些提交)一种奇怪的非分支方法它所做的提交不处于"任何状态分支,但现在已安全地存储在存储库中,因此您现在可以切换分支,然后应用"存储:

This commits your code (yes, it really does make some commits) usinga weird non-branch-y method. The commits it makes are not "on" anybranch but are now safely stored in the repository, so you can nowswitch branches, then "apply" the stash:

$ git checkout develop
Switched to branch 'develop'
$ git stash apply

如果一切顺利,并且您喜欢结果,则应该git stash drop隐藏.这将删除对奇怪的非branch-y提交的引用. (它们仍在存储库中,有时可以在紧急情况下进行检索,但是出于大多数目的,您应该考虑到它们已消失.)

If all goes well, and you like the results, you should then git stash drop the stash. This deletes the reference to the weird non-branch-y commits. (They're still in the repository, and can sometimes be retrieved in an emergency, but for most purposes, you should consider them gone at that point.)

apply步骤使用Git强大的底层合并机制合并隐藏的更改,与分支合并时使用的相同.这意味着,如果您错误地处理的分支与您要处理的分支有足够的差异,则可能会出现合并冲突".因此,在假定存储完全干净之前,仔细检查结果是一个好主意,即使Git本身未检测到任何合并冲突也是如此.

The apply step does a merge of the stashed changes, using Git's powerful underlying merge machinery, the same kind of thing it uses when you do branch merges. This means you can get "merge conflicts" if the branch you were working on by mistake, is sufficiently different from the branch you meant to be working on. So it's a good idea to inspect the results carefully before you assume that the stash applied cleanly, even if Git itself did not detect any merge conflicts.

许多人使用git stash pop,这是git stash apply && git stash drop的简写.就目前而言,这很好,但这意味着,如果应用程序导致混乱,并且您决定不想沿着这条路走下去,就无法轻易地收回藏匿处.这就是为什么我建议单独的apply,仅当/满足时检查结果,drop. (当然,这确实引入了另一个要点,您可以再次休息一下,而忘记自己在做什么,再回来做错误的事情,所以这不是完美的解决方法.)

Many people use git stash pop, which is short-hand for git stash apply && git stash drop. That's fine as far as it goes, but it means that if the application results in a mess, and you decide you don't want to proceed down this path, you can't get the stash back easily. That's why I recommend separate apply, inspect results, drop only if/when satisfied. (This does of course introduce another point where you can take another coffee break and forget what you were doing, come back, and do the wrong thing, so it's not a perfect cure.)

git stash save中的save是用于创建新存储的旧动词. Git版本2.13引入了新动词,以使内容与pop更加一致,并为创建命令添加更多选项. Git版本2.16正式弃用了旧的动词(尽管它仍然可以在Git 2.23中使用,这是我在编辑它时的最新版本).

The save in git stash save is the old verb for creating a new stash. Git version 2.13 introduced the new verb to make things more consistent with pop and to add more options to the creation command. Git version 2.16 formally deprecated the old verb (though it still works in Git 2.23, which is the latest release at the time I am editing this).

这篇关于git switch分支而不丢弃本地更改的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-04 21:13