一、分支的创建与合并
Git 的分支功能十分强大,并且 Git 十分鼓励你使用分支。这样既安全,又能保质保量完成工作。
创建分支之前看一下 readme.txt
文档中的内容:

创建分支
$ git checkout -b dev
Switched to a new branch 'dev'
git checkout
命令加上 -b
参数表示创建并切换,相当于以下两条命令:
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
可以使用 git branch
命令查看当前分支:
$ git branch
* dev
master
git branch
命令会列出当前所有分支,并且你当前所在哪个分支,哪个分支前面会有一个 *
号。
修改 readme.txt
文档,新增:
分支练习 branch test

然后 add
commit
,提交到仓库。
然后回到 master
主分支:
$ git checkout master
Switched to branch 'master'
这时,再打开 readme.txt
文档:

咦?新增的内容哪去了?
聪明的你一定知道,新增的内容在 dev
分支中呢。那怎么把它合并过来呢?
$ git merge dev
Updating 5fa66d6..822955b
Fast-forward
readme.txt | 2 ++
1 file changed, 2 insertions(+)

这样就把 dev
分支中新增的内容合并过来了,并且可以看到,Git 打印出本次的合并方式信息, Fast-forward
信息。这表示本次合并是“快进模式”,也就是直接把 master
指向 dev
的当前提交,所以合并速度非常快。
当然,也不是每次合并都能 Fast-forward
,我们后面会讲其他方式的合并。
合并完之后,就可以把 dev
分支删除了。
这样的做法,既对主分支安全,又不耽误工作进度。
-
查看分支:git branch
-
创建分支:git branch <name>
-
切换分支:git checkout <name>
-
创建+切换分支:git checkout -b <name>
-
合并某分支到当前分支:git merge <name>
-
删除分支:git branch -d <name>
二、解决冲突
合并分支的时候,肯定不能每次都是快速合并。一定会有冲突出现的时候。那在 Git 中出现冲突时,怎么解决冲突呢?
先创建一个 other
分支:
$ git checkout -b other
Switched to a new branch 'other'
$ git branch
master
* other
然后再 other
分支中修改 readme.txt
文档:

然后提交:
$ git add .
$ git commit -m "other branch"
[other 4975a06] other branch
1 file changed, 2 insertions(+)
回到 master
主分支,修改主分支下 readme.txt
文档:

提交:
$ git add .
$ git commit -m "master branch"
[master bf1e782] master branch
1 file changed, 2 insertions(+)
这时候, master
和 other
分支中都对 readme.txt
文档进行了修改,并且修改内容不相同。那次是合并分支的话,就一定会有冲突发生:
$ git merge other
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
果然!Git告诉我们, readme.txt
文件存在冲突,必须手动解决冲突后再提交。 git status
也可以告诉我们冲突的文件:
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
我们可以去 readme.txt
查看冲突的详细情况:

Git用 <<<<<<<
, =======
, >>>>>>>
标记出不同分支的内容。
我们把冲突修改好后保存,然后提交:

$ git add .
$ git commit -m "resolve conflict"
[master 2d51e2f] resolve conflict
再查看下此时仓库的状态:
$ git status
On branch master
nothing to commit, working tree clean
也可以用 git log
查看当前仓库的分支情况:
$ git log
commit 2d51e2fdf0acbd7ba3c49cbd5cfc0bb498b1dc66 (HEAD -> master)
Merge: bf1e782 4975a06
Author: gink <wang_gk@foxmail.com>
Date: Fri Dec 1 16:52:39 2017 +0800
resolve conflict
commit bf1e782ec5a13e6418c66d369266878c6ed8f266
Author: gink <wang_gk@foxmail.com>
Date: Fri Dec 1 16:48:45 2017 +0800
master branch
commit 4975a06fa32408713c3bd51daef9a0173b315b88 (other)
Author: gink <wang_gk@foxmail.com>
Date: Fri Dec 1 16:45:53 2017 +0800
other branch
commit 822955ba048e9e916f002b60145090c26ecf49d0
Author: gink <wang_gk@foxmail.com>
Date: Fri Dec 1 15:51:59 2017 +0800
最后,删除 other
分支。
$ git branch -d other
Deleted branch other (was 4975a06).
三、分支管理策略
实际开发中,我们应该按照几个基本原则进行分支管理:
-
首先,
master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活; -
干活都在
dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本; 你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:

Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward
合并就看不出来曾经做过合并。
四、Bug 分支
开发软件时,肯定少不了与 bug 打交道。在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
加入此时你在 dev 分支上进行开发,突然接到任务要修复一个bug。之前我们介绍过 Git 强大的分支管理,你一定印象深刻。所以此时你一定想要建立一个 issue-1 分支专门修复 bug。但你在 dev 分支上还有未提交的工作,并且此时你还不想提交。这时应该怎么办呢?
$ git status
On branch dev
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
Git 有一个 stash
功能,可以把此时的工作现场隐藏起来。
$ git stash
Saved working directory and index state WIP on dev: 2d51e2f resolve conflict
$ git status
On branch dev
nothing to commit, working tree clean
这时,再查看工作区,发现是干净的。
现在你可以放心地去解决bug了。
首先你需要确定你在哪个分支上解决bug,假如你在 master
分支上去修复。那就要在 master
分支上建立临时分支:
$ git checkout master
Switched to branch 'master'
$ git checkout -b issue-1
Switched to a new branch 'issue-1'
现在修复bug,在 readme.txt
原有文档最后添加一句:

提交到仓库:
$ git add .
$ git commit -m "解决冲突"
[issue-1 d911d5a] 解决冲突
1 file changed, 1 insertion(+)
修复完bug 后,回到 master 分支,完成合并,并删除 issue-1
分支:
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff -m "merged bug fix 101" issue-1
Merge made by the 'recursive' strategy.
readme.txt | 1 +
1 file changed, 1 insertion(+)
这时,可以回到 dev
分支继续干活了。
使用命令 git stash list
命令查看暂存的工作现场。
然后恢复工作现场有两种方式:
1是 git stash apply
,但是恢复后,stash内容并不删除,你需要用 git stash drop
来删除;
2是 git stash pop
,恢复的同时把stash内容也删了:
$ git stash pop
On branch dev
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: readme.txt
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (12eb516e441b9e596c720ea88075b298e4290c4e)
到此,建立 bug 分支解决 bug 的操作就完结了。
五、Feature分支
除了 bug,平时的开发工作中也不免要往项目中添加新功能。
添加新功能时,也要建立一个新分支,避免把主分支搞混乱。通常是建立一个 feature
分支,在上面开发,完成后,合并,最后,删除该 feature
分支。
六、多人协作
当你从远程仓库克隆时,实际上Git自动把本地的 master
分支和远程的 master
分支对应起来了,并且,远程仓库的默认名称是 origin
。
要查看远程库的信息,用 git remote
:
$ git remote
origin
或者,用 git remote -v
显示更详细的信息:
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
$ git push origin master
如果要推送其他分支,比如 dev
,就改成:
$ git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
-
master
分支是主分支,因此要时刻与远程同步; -
dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步; -
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
-
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!

网友评论