Git学习日记(5)

分支管理策略

在实际开发中，分支管理的几个基本原则：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

所有开发者都在dev分支上干活，每个人都有自己的分支，时不时往dev分支上合并。看起来就像这样：

bug分支

当软件开发中有了bug需要修复，每个bug都可以通过一个新的临时分支来修复，修复后合并分支，然后将临时分支删除。

当接到一个修复一个代号为101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，当前在dev上进行的工作还没有提交：



此时工作只进行到一般，还没法提交，预计完成还需要1天的时间。但是，必须在2个小时内修复该bug，怎么办?

Git 提供了一个stash功能，可以把当前工作现场保存起来，以后回复现场后继续工作：



现在，用git status查看工作区，就是干净的，此时可以放心创建分支来修复bug。

首先确定要在哪个分支上修复bug，嘉定需要在master分支上修复，就从master创建临时分支：



bug修复完成后，切换到master分支，完成合并，最后删除issue-101分支：



然后返回dev分支工作，此时git status查看一下工作区的状态，发现工作区是干净的，刚才的工作现场保存到哪去了？

用git stash list命令查看

mjvcp@thinkpad:~/learngit$ git stash list
stash@{0}: WIP on dev: a7ac4e3 change

工作现场还在，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/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

小结

修复bug时，通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，在git stash pop，回到工作现场。