Git的原理与使用 -- 分支管理

目录

• 理解分支
• 创建、切换、合并分支
• 删除分支
• 合并冲突
• 合并模式
• 分支策略
• bug分支
• 强制删除分支

理解分支

Git 的核心就是通过分支来管理不同的开发线 。它让你能在同一个代码库中，同时进行多个功能的开发或多个版本的维护，而互不干扰。分支只要没有与主分支进行合并，就可以自由进行开发，并且不会影响到主分支 ，功能完成后，再将其合并回主分支。
HEAD 指针，这是一个特殊的指针，它指向你当前正在工作的那个分支。你可以把 HEAD 理解为"你本人"，你站在哪个分支上，你对代码的所有修改就会记录在哪个分支上 。

每次提交，master分支都会向前移动⼀步，这样，随着你不断提交，master分支的线也越来越长,而HEAD只要⼀直指向master分支即可指向当前分支。

通过查看当前的版本库，我们也能清晰的理出思路:

[zx@aliyun gitcode]$ cat .git/HEAD 
ref: refs/heads/master
[zx@aliyun gitcode]$ cat .git/refs/heads/master 
87e0759d4687940bfd1e065bd66bff1535522ebb

创建、切换、合并分支

git status命令可以可以查看当前在哪个分支上

[zx@aliyun gitcode]$ git status
On branch master    -- 在master分支上
nothing to commit, working tree clean

git branch命令可以查看当前仓库有哪些分支，*代表HEAD指针所指向的分支。

[zx@aliyun gitcode]$ git branch
* master

创建分支

[zx@aliyun gitcode]$ git branch dev  -- 创建dev分支
[zx@aliyun gitcode]$ git branch       -- 查看当前仓库所有分支
  dev
* master    -- HEAD所指向的分支，就是当前正在工作的分支

.git目录下会出现dev分支

[zx@aliyun gitcode]$ cat .git/refs/heads/*
ce7146da103a372e91208b104c5403a550ab5382
ce7146da103a372e91208b104c5403a550ab5382

切换分支

[zx@aliyun gitcode]$ git checkout dev   --切换分支，切换到dev分支下
Switched to branch 'dev'
[zx@aliyun gitcode]$ git branch     *表示HEAD指针已经指向de分支了
* dev
  master

当前dev分支内容修改不会影响主分支

[zx@aliyun gitcode]$ cat ReadMe      --修改前
hello world
[zx@aliyun gitcode]$ vim ReadMe 
[zx@aliyun gitcode]$ cat ReadMe     -- 当前在dev分支下
hello world
hello world    --修改内容
[zx@aliyun gitcode]$ git status
On branch dev
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   ReadMe
no changes added to commit (use "git add" and/or "git commit -a")
[zx@aliyun gitcode]$ git add .
[zx@aliyun gitcode]$ git commit -m'mf ReadMe:hello world'
[dev ce7146d] mf ReadMe:hello world
 1 file changed, 1 insertion(+)
[zx@aliyun gitcode]$ git checkout  master     --切换到主分支
Switched to branch 'master'
[zx@aliyun gitcode]$ cat ReadMe     --主分支没有被修改
hello world

因为我们是在dev分支上提交的，而master分支此刻的提交点并没有变，此时的状态如图如下所示：

当切换到master分支时，HEAD就指向HEAD了，就看不到dev的最新提交了。
合并分支

[zx@aliyun gitcode]$ git checkout  master   -- 切换主分支
Already on 'master'
[zx@aliyun gitcode]$ git merge dev   -- 将dev分支合并到master分支上
Updating 10d4e89..ce7146d
Fast-forward    -- 快进模式
 ReadMe | 1 +
 1 file changed, 1 insertion(+)
[zx@aliyun gitcode]$ cat ReadMe 
hello world
hello world

Fast-forward 代表"快进模式"，也就是直接把master指向dev的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward。

注意：未提交的修改是工作区的修改，它不属于任何分支，而是属于你的工作目录 。当你切换分支时，如果这个修改与目标分支不冲突，那么修改会跟随你的工作目录一起带到目标分支。如果冲突，Git会拒绝切换，要求你先处理这些修改。工作目录和暂存区的状态是独立于分支的。

删除分支

删除分支时，不能在当前分支删除当前分支。删除分支使用的指令是

git branch -d [分支名]

[zx@aliyun gitcode]$ git branch
* dev      --表示在dev分支下
  master
[zx@aliyun gitcode]$ git branch -d dev    --删除分支dev
error: Cannot delete branch 'dev' checked out at '/home/zx/gitcode'

在其他分支删除dev分支

[zx@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
[zx@aliyun gitcode]$ git branch -d dev
Deleted branch dev (was ce7146d).
[zx@aliyun gitcode]$ git branch
* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用=用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是⼀样的，但过程更安全。

合并冲突

先创建一个新的分支dev1,并且修改ReadMe1文件中的内容，进行add和commit。

[zx@aliyun gitcode]$ git checkout -b dev1        --切换分支，如果不存在就创建该分支
Switched to a new branch 'dev1'
[zx@aliyun gitcode]$ cat ReadMe                  --修改前ReadMe的内容
hello world
hello world
[zx@aliyun gitcode]$ vim ReadMe 
[zx@aliyun gitcode]$ cat ReadMe                   --修改后ReadMe的内容
hello world
I am codeing...
[zx@aliyun gitcode]$ git add .        
[zx@aliyun gitcode]$ git commit -m'my ReadMe:I am coding...'   --提交到版本库中
[dev1 383933d] my ReadMe:I am coding...
 1 file changed, 1 insertion(+), 1 deletion(-)
[zx@aliyun gitcode]$ git checkout master             --切换分支master
Switched to branch 'master'
[zx@aliyun gitcode]$ cat ReadMe        --master下的ReadMe文件内容不会被修改
hello world
hello world

此时我们修改master分支下ReadMe文件中的内容，并进行add和commit。

[zx@aliyun gitcode]$ vim ReadMe 
[zx@aliyun gitcode]$ cat ReadMe 
hello world
xxx code
[zx@aliyun gitcode]$ git add .
[zx@aliyun gitcode]$ git commit -m'my ReadMe:xxx code'
[master ad6a1c4] my ReadMe:xxx code
 1 file changed, 1 insertion(+), 1 deletion(-)

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

两个分支下的ReadMe版本不一致了，将两个分支进行合并会产生合并冲突。

[zx@aliyun gitcode]$ git merge dev1
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe     --产生了冲突
Automatic merge failed; fix conflicts and then commit the result.

ReadMe文件中的内容就变成这样，需要我们自己手动去解决冲突。

[zx@aliyun gitcode]$ 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

no changes added to commit (use "git add" and/or "git commit -a")

发现 ReadMe 文件有冲突后，可以直接查看文件内容，要说的是 Git 会用<<<<<<<，=======，>>>>>>> 来标记出不同分支的冲突内容，如下所示：

[zx@aliyun gitcode]$ cat ReadMe 
hello world
<<<<<<< HEAD
xxx code
=======
I am codeing...
I am codeing...
>>>>>>> dev1

此时我们必须要手动调整冲突代码，并需要再次提交修正后的结果！！（再次提交很重要，切勿忘记）

[zx@aliyun gitcode]$ cat ReadMe 
hello world
xxx code
I am codeing...
I am codeing...
[zx@aliyun gitcode]$ git add .
[zx@aliyun gitcode]$ git commit -m'mf ReadMe'      --修改后需要再次commit一次
[master 5f4ce61] mf ReadMe
[zx@aliyun gitcode]$ git status
On branch master
nothing to commit, working tree clean

到这里冲突就解决完成，此时的状态变成了：

此时dev1分支并没有改变，并没有指向最新的一次commit。

[zx@aliyun gitcode]$ git checkout dev1    --切换分支
Switched to branch 'dev1'
[zx@aliyun gitcode]$ cat ReadMe 
hello world
I am codeing...
I am codeing...

最后，不要忘记 dev1 分支使用完毕后就可以删除了。

[zx@aliyun gitcode]$ git checkout master   -- 切换分支
Switched to branch 'master'
[zx@aliyun gitcode]$ git branch -d dev1  --删除分支
Deleted branch dev1 (was 82dd0f9).
[zx@aliyun gitcode]$ git branch    --查看分支
* master

合并模式

通常合并分支时，如果可能，Git 会采用 Fast forward 模式。还记得如果我们采用 Fast

forward 模式之后，形成的合并结果是什么呢？回顾⼀下：

在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提交到底是 merge 进来的还是正常提交的。

但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为：

那么这就不是 Fast forward 模式了，这样的好处是，从分支历史上就可以看出分支信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分支，但依旧能看到 master 其实是由其他分支合并得到：

[zx@aliyun gitcode]$ git log --graph --pretty=oneline --abbrev-commit
*   54f17ed (HEAD -> master) my ReadMe   --合并得到的
|\  
| * 93709de (dev) my ReadMe
* | 0ba7c2b my ReadMe
|/  
* 6211df6 my ReadMe

Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成⼀个新的 commit ，这样，从分支历史上就可以看出分支信息。

下面我们实战⼀下 --no-ff 方式的 git merge 。

首先，创建新的分支dev2 ，并切换至新的分支，修改ReadMe文件内容：

[zx@aliyun gitcode]$ git checkout  -b dev2
Switched to a new branch 'dev2'
[zx@aliyun gitcode]$ vim ReadMe 
[zx@aliyun gitcode]$ cat ReadMe 
hello world
code ...
[zx@aliyun gitcode]$ git add .
[zx@aliyun gitcode]$ git commit -m'my ReadMe'
[dev2 3aecd1f] my ReadMe
 1 file changed, 1 insertion(+), 3 deletions(-)

直接进行master主分支合并，请注意 --no-ff 参数，表示禁用 Fast forward 模式。禁用Fast forward 模式后合并会创建⼀个新的 commit ，所以加上 -m 参数，把描述写进去。

[zx@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
[zx@aliyun gitcode]$ git merge --no-ff -m'mf ReadMe' dev2
Merge made by the 'recursive' strategy.
 ReadMe | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
[zx@aliyun gitcode]$ git log --graph --pretty=oneline --abbrev-commit
*   f6fa903 (HEAD -> master) mf ReadMe
|\  
| * 3aecd1f (dev2) my ReadMe
|/  
*   54f17ed my ReadMe

可以看到，不使用 Fast forward 模式，merge后就像这样：

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

分支策略

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

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

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

总结就是master主分支就是稳定的，想要进行开发需要在其他分支上，等到其他分支的版本测试完成后，在合并到master分支上，保证master分支的稳定性。

bug分支

假如我们现在正在 dev2 分支上进行开发，开发到⼀半，突然发现 master 分支上⾯有 bug，需要解决。在Git中，每个 bug 都可以通过⼀个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。可现在 dev2 的代码在工作区中开发了⼀半，还无法提交，怎么办？

注意：如果存在多个分支，某一个分支修改了工作区的内容，但是并没有commit，那么其他分支也可以看到相应修改的内容。

所以如果master主分支上出现了bug，需要新建一个分支去修补bug，此时dev2分支还没有提交，正在开发中，我们可以使用git stash命令，先将dev2分支下的工作区中的内容保存起来，再进行bug分支的修改。

[zx@aliyun gitcode]$ git checkout dev2
Switched to branch 'dev2'
[zx@aliyun gitcode]$ vim ReadMe   --dev2修改内容，还没有提交
[zx@aliyun gitcode]$ git checkout master 
M	ReadMe    --主分支的ReadMe文件被修改
Switched to branch 'master'

保存dev2的工作区中的内容。

Git 提供了 git stash 命令，可以将当前的工作区信息进行储藏，被储藏的内容可以在将来某个时间恢复出来。

[zx@aliyun gitcode]$ git checkout dev2
M	ReadMe
Switched to branch 'dev2'
[zx@aliyun gitcode]$ git stash   --保存工作区中的内容
Saved working directory and index state WIP on dev2: 3aecd1f my ReadMe
[zx@aliyun gitcode]$ git status   --保存成功，工作区是干净的
On branch dev2
nothing to commit, working tree clean

创建fix-bug分支修补bug.

[zx@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
[zx@aliyun gitcode]$ git checkout -b fix-bug   --创建分支
Switched to a new branch 'fix-bug'
[zx@aliyun gitcode]$ git checkout  fix-bug     --切换分支
Already on 'fix-bug'
[zx@aliyun gitcode]$ vim ReadMe  --修补bug
......
[zx@aliyun gitcode]$ git add .
[zx@aliyun gitcode]$ git commit -m'fix bug'
[fix-bug a4c86db] fix bug
 1 file changed, 3 insertions(+)

修补完成后，与主分支进行合并。

[zx@aliyun gitcode]$ git checkout master 
Switched to branch 'master'
[zx@aliyun gitcode]$ git merge --no-ff -m'fix bug' fix-bug
Merge made by the 'recursive' strategy.
 ReadMe | 3 +++
 1 file changed, 3 insertions(+)

此时可以恢复dev2分支的工作区，让dev2继续工作了。

[zx@aliyun gitcode]$ git checkout dev2 
Switched to branch 'dev2'
[zx@aliyun gitcode]$ git status
On branch dev2
nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了？用 git stash list 命令看看

[zx@aliyun gitcode]$ git stash list 
stash@{0}: WIP on dev2: 3aecd1f my ReadMe

工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复⼀下，如何恢复现场呢？我们可以使用 git stash pop 命令，恢复的同时会把 stash 也删了，示例如下：

[zx@aliyun gitcode]$ git stash pop
On branch dev2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   ReadMe

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (59765bc1e9170d3fe51df32b870b5fe7e4f1c523)

[zx@aliyun gitcode]$ git status
On branch dev2
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   ReadMe

no changes added to commit (use "git add" and/or "git commit -a")

但我们注意到了，修复 bug 的内容，并没有在 dev2 上显示。此时的状态图为：

此时dev2是看不见fix-bug修改的代码的，因为Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们在 dev2 中当然看不见修复 bug 的相关代码。

但是在将dev2合并到master时，可能会产生合并冲突，此时我们又需要去解决冲突，修改代码，在master分支上修改代码是有一定的风险的。

因此我们可以现将master的分支合并到dev2分支上，在dev2分支上来解决冲突

冲突解决后，在将dev2分支合并到master上。

强制删除分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加⼀个新功能时，你肯定不希望因为⼀些实验性质的代码，把主分支搞乱了，所以，每添加⼀个新功能，最好新建⼀个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最后，删除该 feature 分支。

可是，如果我们今天正在某个 feature 分支上开发了⼀半，被产品经理突然叫停，说是要停止新功能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统的 git branch -d 命令删除分支的方法是不行的。演示如下：

[zx@aliyun gitcode]$ git branch  -d dev     -- 使用git branch -d 是删除不了的
error: The branch 'dev' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev'.

也就是说，如果你在一个分支上修改了内容，但是没有进行合并，git branch -d 命令是删除不了该分支的，因此我们可以使用git branch -D

[zx@aliyun gitcode]$ git branch  -D dev
Deleted branch dev (was a4c86db).