【Todo】git的fast forward & git命令学习 & no-ff

git的fast-forward在之前的文章有介绍过,但是介绍的不细:

http://www.cnblogs.com/charlesblc/p/5953066.html

 


复制代码
fast-forward方式就是当条件允许的时候,git直接把HEAD指针指向合并分支的头,完成合并。属于“快进方式”,不过这种情况如果删除分支,则会丢失分支信息。
因为在这个过程中没有创建commit squash 是用来把一些不必要commit进行压缩,比如说,你的feature在开发的时候写的commit很乱,那么我们合并的时候不希望把这些历史commit带过来,
于是使用--squash进行合并,此时文件已经同合并后一样了,但不移动HEAD,不提交。需要进行一次额外的commit来“总结”一下,然后完成最终的合并。 --no-ff指的是强行关闭fast-forward方式。
复制代码

有这篇文章详细复习一下 (Link)

 

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

如果要强制禁用Fast forward模式,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 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

 

关于默认的fast-forward的,上面引文没有详述。基本就是看不出有从其他分支合并过来的信息,只能看到每个commit实际的信息。如果其他分支丢失了,分支合并的信息就丢失了。

 

我自己试了一下 默认的有fast-forward的情况。如下:

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

$ vi readme

$ git add readme

$ git commit readme
test ff
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Explicit paths specified without -i or -o; assuming --only paths...
# On branch testff
# Changes to be committed:
#   new file:   readme
#
...
".git/COMMIT_EDITMSG" [converted] 8L, 282C written [testff 5a036ee] test ff 1 file changed, 1 insertion(+) create mode 100644 readme $ git checkout -b newtestff Switched to a new branch 'newtestff' $ git merge testff Already up-to-date. $ git diff testff newtestff $ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. $ git pull $ git checkout -b newff Switched to a new branch 'newff' $ git checkout newff Already on 'newff' $ git merge testff Updating 30a974d..5a036ee Fast-forward readme | 1 + 1 file changed, 1 insertion(+) create mode 100644 readme $ git log --graph --pretty=oneline --abbrev-commit * 5a036ee test ff * 30a974d Merge branch 'xxx' into master |\ ...

重点看两点:

1. 第一处飘黄的地方,是在test-ff版本 checkout -b的,结果发现git 两个branch完全没有差别。

git checkout -b dev命令相当于 
创建分支: gibrancde git checkout dev 

而这个创建是基于当前HEAD的。

所以新创建的分支和test-ff没有区别。

 

2. 采用默认的merge之后,使用git log --graph --pretty=oneline --abbrev-commit 能够看到:

* 5a036ee test ff

完全没有原来 test-ff 分支的信息。

另,git log命令加上后面的参数很好用,--graph --pretty=oneline --abbrev-commit

比原始的输出好看多了。

 

分支策略

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

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

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

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

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

git-br-policy

小结

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

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

 

一些git命令:

git checkout -b dev//基于本地创建分支

git checkout -b dev origin/dev //基于远程分支创建本地分支

可以看到git checkout -b命令相当于 
创建分支: git branch dev切换分支: git checkout dev 
是基于当前HEAD的

删除本地分支
git branch -D dev

删除远程分支
git push origin :branch-name
冒号后面没有空格

 

下面再对这些内容做一下复习:

http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html

http://www.ruanyifeng.com/blog/2015/08/git-use-process.html

http://www.ruanyifeng.com/blog/2014/06/git_remote.html

 

posted @ 2016-12-04 23:30  blcblc  阅读(14719)  评论(0编辑  收藏  举报