Git版本控制：Git分支处理

http://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

git分支使用

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

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

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

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

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

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

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

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

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

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

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鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

[创建与合并分支]

分支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，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--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 merge1 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 Rebase

不怎么好用，有风险。

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

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

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

[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 merge --spuash减少dev上的commit数。

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

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

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

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

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

[分支管理策略]

皮皮Blog

写保护分支

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

[About protected branches]

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

ref:learnGitBranching-demo