git深入操作之分支管理

• 分支：就是暂时不想提交到本地库的内容。

在smartgit下可以看到只有一条时间线，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。如下图：

• 当我们创建新的分支

例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

注：1、创建分支操作：

通过以上图文并茂的展示，其实也是对git操作深入之创建版本库、本地仓库管理里操作的一个解释。

第一种方式：git checkout命令加上-b参数表示创建并切换，如下图：可以看到箭头处已经切换到dev了。

第二种方式：git branch dev(创建） 再执行 git checkout dev（到分支上）

注：切换分支，上面用的git checkout XX,实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

2、查看分支 git branch

 当前分支前面会标一个*号

• 合并

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

 使用git merge:可以看到已经和ljb（分支库）最新提交的文档一样了。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，要具体情况具体分析。

要强制禁用Fast-forward,使用普通模式合并，如下，要创建一个新的提交

注意--no-ff参数，表示禁用Fast forward

-m参数，把新commit描述写进去,这样每次合并，就会有记录了，比较符合实际情况 。

• 删除分支

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

合并后，就可以删除分支了。

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

• 分支管理策略：

基本原则:

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

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

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

bug分支管理：bug分支，也是分支，可以看作是普通的分支，但操作bug(或突然想起来的要更改的程序点）要先暂停当前的分支操作，如何暂停呢？

stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

可以看到执行stash后，工作区变成了刚克隆后的状态或修改之前的状态。

暂停当的工作后，就可以通过创建BUG分支来先做其他要紧的工作了。

进行到这一步：要先确定在哪个分支上来创建bug分支，并且用git switch切换到此分支上。再在那个分支上创建新的bug分支。

修改好后，提交新的文件到bug分支，再合并到所在的分支，如下以master上创建bug分支，基本步骤如下：

切换回源分支后，之前保存的现场如何恢复呢？

先用git stash list,看一下还在吧？

还在，有两种方式恢复：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了，如下：

针对多次stash情况：恢复的时候，先用git stash list查看，然后恢复指定的stash，如：git stash apply stash@{0} 

注：stash@{0}即用git stash list查出来stash的标识名

对于相同的bug,存在于其他分支上的情况，git提供了git cherry-pick ,把bug提交的修改“复制”到当前分支，避免重复劳动。

由于是刚创的一个分支，没有bug，所以提示是空的。 可以通过git log得到提交的ID.

Feature（特性）分支管理：

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

如果要丢弃一个没有被合并进master的分支，可以通过git branch -D 强行删除。

多人协作管理：

• 查看远程分支：

git remote：显示出远程仓库的name

git remote -v:显示远程仓库抓取和推送的地址。

• 推送本地分支：

和远程仓库管理推送本地到远程一样，只不过那里多-u,来关联远程与本地端的master分支。

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

• 抓取分支管理：

1. 首先，可以试图用git push origin 推送自己的修改；

可以看到执行git push时，远程库没有dev分支，现在远程库创建了一个远程dev分支。

也可以通过git checkout -b dev origin/dev，来创建一个本地和远程库分支，两个名称最好一样。

若名称不一样，也可通过git branch --set-upstream-to=,建立关联。

 2、如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，git branch --set-upstream-to=,建立关联，见1，若分支名称不一致。

3、如果合并有冲突，则解决冲突，并在本地提交；

4、没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

• ​​​​​​​git rebase

​​​​​​​rebase操作的特点：把分叉的提交历史“整理”成一条直线，这样提交到远程库上去看起来更直观。

扩展：

以上的情况针对的是顺利的情况，若出现冲突时，要先解决冲突。如下：

要修改掉两个文件的不同。打开源文件，也可以看到不同的点。Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

git log --graph查看合并后的图：