软件开发中,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,怎么办?
∗∗gitstash∗∗
幸好,Git
还提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
现在,用git status
查看工作区,就是干净的
(除非有没有被Git管理的文件),
git checkout master
创建bug分支
因此可以放心地创建分支来修复bug
。
首先确定要在哪个分支上修复bug
,假定需要在master
分支上修复,就从master
创建临时分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
$ git checkout -b issue-101
Switched to a new branch 'issue-101'
修复Bug
现在修复bug,需要把“Git is free software …”改为“Git is a free software …”,然后提交:
git add … git commit … (修复好了)
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
1 file changed, 1 insertion(+), 1 deletion(-)
git merge --no-ff … issue-101 (合并修复)
修复完成后,切换到master分支,并完成合并,最后删除issue-101分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local 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(-)
太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到dev分支干活了!