[廖雪峰] Git 分支管理:Bug 分支
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[廖雪峰] Git 分支管理:Bug 分支相关的知识,希望对你有一定的参考价值。
软件开发中,bug 就像家常便饭一样。有了 bug 就需要修复,在 Git 中,由于分支是如此的强大,所以,每个 bug 都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号 101 的 bug 的任务时,很自然地,你想创建一个分支 issue-101
来修复它,但是,等等,当前正在 dev
上进行的工作还没有提交:
$ git status # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: readme.txt #
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需 1 天时间。但是,必须在两个小时内修复该 bug,怎么办?
幸好,Git 还提供了一个 stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$ git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 add merge
现在,用 git status
查看工作区,就是干净的(除非有没有被 Git 管理的文件),因此可以放心地创建分支来修复 bug。
首先确定要在哪个分支上修复 bug ,假定需要在 master
分支上修复,就从 master
创建临时分支:
$ git checkout master Switched to branch ‘master‘ Your branch is ahead of ‘origin/master‘ by 6 commits. $ git checkout -b issue-101 Switched to a new branch ‘issue-101‘
现在修复 bug,需要把“Git is free software ...”改为“Git is a free software ...”,然后提交:
$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 cc17032] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后,切换到 master
分支,并完成合并,最后删除 issue-101
分支:
$ git checkout master Switched to branch ‘master‘ Your branch is ahead of ‘origin/master‘ by 2 commits. $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the ‘recursive‘ strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-101 Deleted branch issue-101 (was cc17032).
太棒了,原计划两个小时的 bug 修复只花了 5 分钟!现在,是时候接着回到 dev
分支干活了!
$ git checkout dev Switched to branch ‘dev‘ $ git status # On branch dev nothing to commit (working directory clean)
工作区是干净的,刚才的工作现场存到哪去了?用 git stash list
命令看看:
$ git stash list [email protected]{0}: WIP on dev: 6224937 add merge
工作现场还在,Git 把 stash 内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用 git stash apply
恢复,但是恢复后,stash 内容并不删除,你需要用 git stash drop
来删除;
另一种方式是用 git stash pop
,恢复的同时把 stash 内容也删了:
$ git stash pop # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: readme.txt # Dropped refs/[email protected]{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)
再用 git stash list
查看,就看不到任何 stash 内容了:
$ git stash list
你可以多次 stash,恢复的时候,先用 git stash list
查看,然后恢复指定的 stash,用命令:
$ git stash apply [email protected]{0}
小结
修复 bug 时,我们会通过创建新的 bug 分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场 git stash
一下,然后去修复 bug,修复后,再 git stash pop
,回到工作现场。
【网友 提问/回答】
问题1:不理解[工作只进行到一半,还没法提交]这句话。为什么不能先在 dev 上提交,然后转去 master 上修 bug,最后转回 dev 上继续写?求解答。
答1:如果只有你一个人开发没问题。但是多人合作时,你向dev提交一个尚未完成的commit,理论来说这个提交是错误的,如果有别人再下载dev分支再去做工作,这就是埋雷了。
答2:多人的话不PUSH是不是就行了?直接commit 上去也不会丢的吧?
答3:但是你后续开发总归还是要 PUSH 的,这时候你之前没有 PUSH 的 commit 会一起被 PUSH 到远程。虽说不是必然出问题,但终究存在隐患。
答4:我感觉 通过分支切换也可以完全不使用 stash 这个功能(个人见解):
关键是当你在某个分支上(比如 dev)还有很多东西没有提交(要切换分支必须 commit 之后)你如果因为另外一个分支需要紧急 bug 修复 而把你现在修改的文件(一般都不止一个)提交的话 之后 你再回来你需要再去查看你的那些代码是完成了一半就提交了的,哪些是真正提交了的。我感觉提交最起码就是你感觉你的代码已经完成一个功能,可以上传了才提交。
答5:因为没完成的工作提交后会影响到其他人。可能你会说,那就不提交了,反正不在一个分支。听着是这么个理,但是请注意不管你现在在哪个分支,工作区和暂存区都是同一个,所以在修复bug时会清掉之前的工作内容
问题2:既然要删除分支,那还加 --no-ff 参数干嘛?
答1:可以查看历史啊,这样就可以回溯了。
如果你实验一下的话,会发现用 ff 模式,删除分之后是没有历史并且无法回溯的。
以上是我的个人见解,仅供参考啊。
摘自:
http://www.liaoxuefeng.com/wiki/0013739516305929606d
实战心得:
上面是 廖老师 关于 修复分支 bug 的一些参考,在实际项目中,我不是通过“新建临时 bug 分支,然后删除该分支”方式处理的, 而是:
通过切换分支,直接在分支上修复 bug。不过,在切换分支之前,先用 phpStorm 自带的“Shelve Changes”功能,保存当前分支的现场,详情查看:
Git 修复 bug 切换分支时,如何保存修改过的代码(即如何保存现场)?
以上是关于[廖雪峰] Git 分支管理:Bug 分支的主要内容,如果未能解决你的问题,请参考以下文章