Git版本控制：Git分支处理

柔光的暖阳◎ 2022-08-02 12:39 156阅读 0赞

http://[blog.csdn.net/pipisorry/article/details/46958699][blog.csdn.net_pipisorry_article_details_46958699]

### 分支的意义 ###

创建分支可以避免提交代码后对主分支的影响，同时也使你有了相对独立的开发环境。

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

分支管理使用基本命令

### **创建并切换到新分支** ###

**git checkout -b new\_branch**

**新建分支**

git branch new\_branch

**查看当前分支**

git branch  
切换到master分支

(dev): git checkout master

**Note**: 切换分支后你会发现本地文件会变化，如果dev分支和master文件不同的话。再cheout回来就又可以看到之前分支的文件了。不过git2.0以上好像都看得到文件。

在dev分支中时，可以通过git pull origin master将master分支上的文件下载到本地当前分支中。  
**合并分支到当前分支**

git merge命令用于合并指定分支到当前分支  
把dev分支的工作成果合并到master分支上：

$(master): git merge dev

合并分支的操作是从new\_branch合并到master分支(这时master的内容就变成了dev的内容)，当前环境在master分支。  
**删除分支**

git branch -d `dev`

`git push origin :dev #将删除操作提交到远程(删除远程分支，注意origin和:之间有空格)`

[皮皮Blog][Blog]

## git分支使用 ##

Git里默认分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

![git-br-initial][]

每次提交，master分支都会向前移动一步。

当创建并进入新的分支dev时

$git checkout -b dev    \#这时是看不到master中的内容，如果想同步master内容到dev，需要使用git merge master

Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

![git-br-create][]

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向！

从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

![git-br-dev-fd][]

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

$git checkout master     \#到master中来时，本地看不到修改的文件及内容

$git merge dev      \#这样master分支和dev分支的内容一样了

![git-br-ff-merge][]

git merge命令用于合并指定分支到当前分支。直接使用git merge的合并是“快进模式”Fast-forward，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能Fast-forward，其它merge策略可参考后面的分支merge策略。

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
    Deleted branch dev (was fec145a).

删除后，查看branch，就只剩下master分支了：$ git branch     \#输出\* master

![git-br-rm][]

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

\[[创建与合并分支][Link 1]\]

## 分支merge策略 ##

### git merge --no-ff dev ###

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

建议使用 git merge --no-ff，这样无论如何都会产生一个新的 merge commit。然后你 git show <merge-commit-sha1> 就可以看到这次 merge 的所有改动。

如果要强制禁用Fast forward模式，添加参数--no-ff，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly95b3V6aXBpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70][]  
下面我们实战一下--no-ff方式的git merge：

首先，仍然创建并切换dev分支：

$ git checkout -b dev
    Switched to a new branch 'dev'

修改readme.txt文件，并提交一个新的commit：

$ git add readme.txt 
    $ git commit -m "add merge"
    [dev 6224937] add merge
     1 file changed, 1 insertion(+)

现在，我们切换回master：

$ git checkout master
    Switched to branch 'master'

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "merge with no-ff" dev
    Merge made by the 'recursive' strategy.
     readme.txt |    1 +
     1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上\-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
    *   7825a50 merge with no-ff
    |\
    | * 6224937 add merge
    |/
    *   59bc1cb conflict fixed
    ...

可以看到，不使用Fast forward模式，merge后就像这样：

![git-no-ff-mode][]

### Git Rebase ###

不怎么好用，有风险。

\[[彻底搞懂 Git-Rebase][Git-Rebase]\]**git merge –squash**

–squash：使用squash方式合并，把多次分支commit历史压缩为一次

git merge –squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，那么我们合并的时候不希望把这些历史commit带过来，于是使用–squash进行合并，此时文件已经同合并后一样了，但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。

\[[git merge 将多个commit合并为一条之--squash 选项][git merge _commit_--squash]\]

### 减少commit/更容易找到回滚点的策略 ###

Note: 需要注意的一点是，无论是git merge dev还是git merge --no-ff dev，在master分支上都能看到dev上提交的所有commit，这样在master上直接找上一个回滚点也是很烦。需要使用

$git log --graph --pretty=oneline --abbrev-commit

这个来查询commit历史，更容易找出master上的commit。\[[Git版本控制][Git]：Git查阅、撤销文件修改和撤销文件追踪\]

或者使用上面的git merge --spuash减少dev上的commit数。

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

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

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

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

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

![git-br-policy][]

\[[分支管理策略][Link 2]\]

[皮皮Blog][Blog]

## 写保护分支 ##

Github推出了“可以写保护的分支”，对多人协作的项目非常有用：不得删除、不得强行推送、只有测试全部通过才接受PR

\[[About protected branches][]\]

from:[http://blog.csdn.net/pipisorry/article/details/46958699][blog.csdn.net_pipisorry_article_details_46958699]

ref:[learnGitBranching-demo][]

[blog.csdn.net_pipisorry_article_details_46958699]: http://blog.csdn.net/pipisorry/article/details/46958699
[Blog]: http://blog.csdn.net/pipisorry
[git-br-initial]: /images/20220731/83a173ac86e04965af80663e827a9de9.png
[git-br-create]: /images/20220731/08fcfe617346447bb2b3526a3d3c7a0f.png
[git-br-dev-fd]: /images/20220731/cf370fd0b9d8430b88804c1426f05e22.png
[git-br-ff-merge]: /images/20220731/746d71417a7746bf9c4fc1b1bfd400bc.png
[git-br-rm]: /images/20220731/70edb5f57f6748b6a1d75c203f68f54d.png
[Link 1]: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840038939c291467cc7c747b1810aab2fb8863508000
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly95b3V6aXBpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70]: /images/20220731/53d3bbcd0b1d4bd2affe31bdac6ff419.png
[git-no-ff-mode]: /images/20220731/3a2492d9a09343059a5d2511c2b3ed3f.png
[Git-Rebase]: http://jartto.wang/2018/12/11/git-rebase/
[git merge _commit_--squash]: https://blog.csdn.net/themagickeyjianan/article/details/80333645
[Git]: https://youzipi.blog.csdn.net/article/details/47867097
[git-br-policy]: /images/20220731/3d2f9609d2114aa994b0ea1a205e3f88.png
[Link 2]: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013758410364457b9e3d821f4244beb0fd69c61a185ae0000
[About protected branches]: https://help.github.com/articles/about-protected-branches/
[learnGitBranching-demo]: http://pcottle.github.io/learnGitBranching/?demo