git 入门（创建与合并分支、解决冲突、分支策略、bug分支）_vc 创建git分支

 学习目标

目录

创建和合并分支

实战

版本冲突

分支策略

Bug分支 

小结

---

 

创建和合并分支

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

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

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

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

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

 

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

 

实战

我们创建dev分支，然后切换到dev分支

$ git checkout -b dev

相当于

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

合并分支 

admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master)
$ git merge dev
Updating 7f10c22..729260b
Fast-forward
 a.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
 
admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master)
$

git merge命令用于合并指定分支到当前分支。合并后，再查看a.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

合并完成后，就

可以放心地删除dev分支了： 

$ git branch -d dev
Deleted branch dev (was 729260b).
 
admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master)
$

 删除 dev  分支后 ，我们再查看 branch  

版本冲突

跟上面的一样，我们创建新的分支，我的新的分支，修改 a.txt 文件的最后一行数字

$ git checkout -b dev1

然后就是 添加到暂存区，提交 

$ git add readme.txt
 
$ git commit -m "AND simple"

切换到master分支：

$ git checkout master

 在 master 分支这里我们也对文件做 修改

1234
123456789
1234556798888888888888888888
 

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

   这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master)
$ git merge dev1
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.

 打开 a.txt 

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

1234
123456789
1234567899999999999
1234556798888888888888888888

 继续提交

admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master|MERGING)
$ git add a.txt
 
admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master|MERGING)
$ git commit -m 'conflict fixed'
[master fbef619] conflict fixed
 

接下来我们的分支节点 master 和 dev 1 ，变成了如下图所示：

查看日志，我们知道分支的合并情况：

$ git log
commit fbef619c5ab10295d91f0fcf2605ad515be9c0c4 (HEAD -> master)
Merge: ae2c9f4 c078908
Author: kangna <kangna68688@aliyun.com>
Date:   Fri Oct 11 19:10:55 2019 +0800
 
    conflict fixed
 
commit ae2c9f498a956d0865e331cb4baf9dec114bdddb
Author: kangna <kangna68688@aliyun.com>
Date:   Fri Oct 11 18:18:32 2019 +0800
 
    master modify a.txt
 
commit c0789081c83485e29fb51125bf370392f31aba07 (dev1)
Author: kangna <kangna68688@aliyun.com>
Date:   Fri Oct 11 18:16:26 2019 +0800
 
    dev1 branch commit
 
commit 729260bbc5029ab4ba86c89a5bcee557238d2bcc
Author: kangna <kangna68688@aliyun.com>
Date:   Fri Oct 11 17:39:08 2019 +0800
 
    branch dev test
 
commit 7f10c22fdd1e3557b5b8ecd322be5719799f157f (origin/master, origin/HEAD)
Author: kangna <kangna68688@aliyun.com>
Date:   Fri Oct 11 16:29:58 2019 +0800
 
    远程克隆
 
commit 3785701f62fed762997b31fa975774df63d0f09f
Author: 康纳 <kangna68688@aliyun.com>
Date:   Fri Oct 11 12:19:57 2019 +0800
 
    first commit
 
admin@DESKTOP-00TUDJ8 MINGW64 ~/Desktop/demo/abvc/abvc (master)

分支策略

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

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

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

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

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

Bug分支 

 

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

 

 接下来修复  bug，修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git merge --no-ff -m "merged bug fix 101" issue-101

 切换到 dev  分支 ， 用git stash list命令看看：

 

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，用git stash pop，恢复的同时把stash内容也删了：

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。（参考廖雪峰网站）