Git 分支管理策略

参考链接:https://www.liaoxuefeng.com/wiki/896043488029600/900005860592480

补充

注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello，本地分支比远程分支快两个提交。

$ git log --graph --pretty=oneline --abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
*   e5e69f1 Merge branch 'dev'
|\  
| *   57c53ab (origin/dev, dev) fix env conflict
| |\  
| | * 7a5e5dd add env
| * | 7bd91f1 add new env

　　

在实际开发中，我们应该按照几个基本原则进行分支管理：

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

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

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

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

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

练习:验证加上--no-ff参数,就能查看合并后的历史分支

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

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

接下来创建一个新的分支并对其中的文件进行修改,然后添加提交.返回master分支

然后使用--no-ff参数合并

$ 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看看分支历史：

*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge#这个就是能够查看的合并#删除dev后也会有分支,只不过少了dev
|/  
*   cf810e4 conflict fixed

不能查看合并历史的分支是这样

λ git merge dev3
Updating 61f64f3..e0d028a
Fast-forward
 readme.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

C:\Users\Administrator.SC-201605202132\learngit (master -> origin)
λ git log --graph --pretty=oneline --abbrev-commit
* e0d028a (HEAD -> master, dev3) 检查是否删除后依然能看出合并过#dev3 没有分支的标记
*   61f64f3 merge with no-ff
|\
| * 5c287fe modify this
|/
*   127f749 conflict fixed
|\
| * fb4d959 and simple
* | 466aa52 & simple
|/
* a8a3763 don't konw what

　　

 

转载于:https://www.cnblogs.com/Gaoqiking/p/11116380.html