4.Bug分支
(1)Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作(即把未完成的其他分支的工作先保存起来,然后完成其他事后再继续)
$ git stash
(2)首先确定要在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支
$ git checkout master
$ git checkout -b bug分支名字
修复并且提交完成后,切换到master分支,完成合并,然后删除bug分支
(3)保存的工作可以用$ git stash list来查看
(4)Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;
$ git stash apply stash@{0}
另一种方式是用git stash pop,恢复的同时把stash内容也删了
(5)Git专门提供了一个cherry-pick命令,让我们能复制一个特定的提交到当前分支(在另外一个分支修复相同的bug)
$ git cherry-pick 4c805e2
(6)小结
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场;
在master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick <commit>命令,把bug提交的修改“复制”到当前分支,避免重复劳动。
5.feature分支
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。
开发一个新feature,最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>强行删除。
6.多人协作
(1)要查看远程库的信息,用git remote;用git remote -v显示更详细的信息
(2)推送分支
$ git push origin 分支名字
(3)需要推送的分支:
master分支是主分支,因此要时刻与远程同步;
dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
(4)其他人要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支
$ git checkout -b dev origin/dev
(5)若其他人的最新提交和你试图推送的提交有冲突,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送。
(6)多人协作的工作模式
首先,可以试图用git push origin <branch-name>推送自己的修改;
如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;
如果合并有冲突,则解决冲突,并在本地提交;
没有冲突或者解决掉冲突后,再用git push origin <branch-name>推送就能成功!
如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
(7)小结
查看远程库信息,使用git remote -v;
本地新建的分支如果不推送到远程,对其他人就是不可见的;
从本地推送分支,使用git push origin branch-name,如果推送失败,先用git pull抓取远程的新提交;
在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;
建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;
从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。
7.Rebase
(1) rebase操作可以把本地未push的分叉提交历史整理成直线
(2)rebase的目的是使得我们在查看历史提交的变化时更容易,因为分叉的提交需要三方对比。