Git 进阶 · 分支篇 • Xiaohei's Blog

前言#

这是对前篇没有展示完全的 git 内容的继续，是真正 git 的开始，继续来吧。

Git 分支管理#

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了 50% 的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

Git 的分支是与众不同的，无论创建、切换和删除分支，Git 在 1 秒钟之内就能完成！无论你的版本库是 1 个文件还是 1 万个文件。

创建与合并分支#

下面开始实战。首先，我们创建 dev 分支，然后切换到 dev 分支：

$ git checkout -b dev   # 创建并切换分支
Switched to a new branch 'dev'

bash

git checkout 命令加上 -b 参数表示创建并切换，相当于以下两条命令：

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

bash

然后，用 git branch 命令查看当前分支：

$ git branch  # 查看当前分支
* dev
  master

bash

git branch 命令会列出所有分支，当前分支前面会标一个 * 号。然后，我们就可以在 dev 分支上正常提交，比如对 readme.txt 做个修改，加上一行文字后，然后进行提交：

$ git add readme.txt 
$ git commit -m "branch test"
[dev b17d20e] branch test
 1 file changed, 1 insertion(+)

bash

现在，dev 分支的工作完成，我们就可以切换回 master 分支：

$ git checkout master   # 切换分支
Switched to branch 'master'

bash

切换回 master 分支后，再查看一个 readme.txt 文件，刚才添加的内容不见了！因为那个提交是在 dev 分支上，而 master 分支此刻的提交点并没有变：

branch

现在，我们把 dev 分支的工作成果合并到 master 分支上，使用命令 git merge：

$ git merge dev   # 合并分支
Updating d46f35e..b17d20e
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

bash

git merge 命令用于合并指定分支到当前分支。合并后，再查看 readme.txt 的内容，就可以看到，和 dev 分支的最新提交是完全一样的。注意到上面的 Fast-forward 信息，Git 告诉我们，这次合并是“快进模式”，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward ，我们后面会讲其他方式的合并。合并完成后，就可以放心地删除 dev 分支了：

$ git branch -d dev   # 删除分支
Deleted branch dev (was b17d20e).

bash

删除后，使用 git branch 查看分支，就只剩下 master 分支了

switch#

我们注意到切换分支使用 git checkout <branch> ，而前面讲过的撤销修改则是 git checkout -- <file> ，同一个命令，有两种作用，确实有点令人迷惑。实际上，切换分支这个动作，用 switch 更科学。因此，最新版本的 Git 提供了新的 git switch 命令来切换分支。创建并切换到新的 dev 分支，可以使用：

$ git switch -c dev

bash

直接切换到已有的 master 分支，可以使用：

$ git switch master

bash

使用新的 git switch 命令，比 git checkout 要更容易理解。

解决冲突#

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。下面就让我们来实际演示一下，先准备新的 feature1 分支，然后继续我们的新分支开发：

$ git switch -c feature1
Switched to a new branch 'feature1'

bash

之后修改一个文件内容，例如，修改readme.txt最后一行，改为： Creating a new branch is quick AND simple.

之后在 feature1 分支上提交：

$ git add readme.txt

$ git commit -m "AND simple"
[feature1 14096d0] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

bash

切换到 master 分支：

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

bash

此时，通过输出就可以看出，Git 还会自动提示我们当前 master 分支比远程的 master 分支要超前 1 个提交。但不要慌张，这并不是错误冲突。

下面我们来看下面这种新的情况，如果此时在 master 分支上把 readme.txt 文件的最后一行改为：Creating a new branch is quick & simple.这时在 master 分支下进行提交，会出现什么情况呢。

$ git add readme.txt    # 在 master 分支下进行提交
$ git commit -m "& simple"
[master 5dc6824] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

bash

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

branch1

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

$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

bash

输出显示果然冲突了！Git 告诉我们，readme.txt 文件存在冲突，必须手动解决冲突后再提交。git status 也可以告诉我们冲突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

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")

bash

用编辑器 VS code 打开有问题冲突的文件 readme.txt，你会看到 Git 标记的冲突内容。我们可以直接查看 readme.txt 的内容：

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

bash

Git 用 <<<<<<<，=======，>>>>>>> 标记出不同分支的内容，我们根据项目的实际需要选择使用哪个修改后进行文件保存。之后即可进行再次提交。

$ git add readme.txt 
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

bash

现在，master 分支和 feature1 分支变成了下图所示：

branch2

用带参数的 git log 也可以看到分支的合并情况，或用 git log --graph 命令可以看到分支合并图：

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file

bash

最后，分支使用完毕之后即可删除 feature1 分支：

$ git branch -d feature1
Deleted branch feature1 (was 14096d0).

bash

分支管理策略#

通常，合并分支时，如果可能，Git 会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。如果要强制禁用 Fast forward 模式，Git 就会在 merge 时生成一个新的 commit，这样，从分支历史上就可以看出分支信息。下面我们实战一下 --no-ff 方式的 git merge。

首先，仍然创建并切换 dev 分支：

$ git switch -c dev
Switched to a new branch 'dev'

bash

修改 readme.txt 文件，并提交一个新的 commit：

$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)

bash

现在，我们切换回 master：

$ git switch master
Switched to branch 'master'

bash

准备合并 dev 分支，请注意 --no-ff 参数，表示禁用 Fast forward，因为本次合并要创建一个新的 commit，所以加上 -m 参数，把 commit 描述写进去：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

bash

合并后，我们用 git log 看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...

bash

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

branch3

分支策略#

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

首先，master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；那在哪干活呢？干活都在 dev 分支上，也就是说，dev 分支是不稳定的，到某个时候，比如 1.0 版本发布时，再把 dev 分支合并到 master 上，在 master 分支发布 1.0 版本；

你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。所以，团队合作的分支看起来就像这样：

branch4

Bug 分支#

下面我们先引入一个场景，当你在开发 dev 分支时，突然有一个要修改 bug 的任务。并且此时你的 dev 分支的工作也才进行了一半，还没办法提交，但项目负责人现在必须让你修复 bug，这怎么办呢。

还好，Git 提供了一个 stash 功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

bash

现在，用 git status 查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复 bug。

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

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'

bash

现在修复 bug，修改完成之后，进行提交。

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

bash

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

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

bash

太棒了，bug 修复完成了！现在，是时候接着回到 dev 分支干活了！先用 git switch dev 切换到 dev 分支，然后再 git status 看一下工作区状态。你会发现，工作区是干净的，刚才的工作现场存到哪去了？用 git stash list 命令看看。

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge

bash

工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复一下，有两个办法：一是用 git stash apply 恢复，但是恢复后，stash 内容并不删除，你需要用 git stash drop 来删除；另一种方式是用 git stash pop，恢复的同时把 stash 内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   hello.py

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

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

bash

此时，再用 git stash list 查看，就看不到任何 stash 内容了。有需要的话，你可以多次 stash ，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令：

$ git stash apply stash@{0}

bash

在 master 分支上修复了 bug 后，我们要想一想，dev 分支是早期从 master 分支分出来的，所以，这个 bug 其实在当前 dev 分支上也存在。那怎么在 dev 分支上修复同样的 bug？一个比较容易想到的方法是重复操作一次，提交不就行了。那有没有更简单的方法呢。

同样的 bug，要在 dev 上修复，我们只需要把 4c805e2 fix bug 101 这个提交所做的修改“复制”到 dev 分支。注意：我们只想复制 4c805e2 fix bug 101 这个提交所做的修改，并不是把整个 master 分支 merge 过来。

为了方便操作，Git 专门提供了一个 cherry-pick 命令，让我们能复制一个特定的提交到当前分支：

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

bash

Git 自动给 dev 分支做了一次提交，注意这次提交的 commit 是 1d4b803 ，它并不同于 master 的 4c805e2 ，因为这两个 commit 只是改动相同，但确实是两个不同的 commit。用 git cherry-pick ，我们就不需要在 dev 分支上手动再把修 bug 的过程重复一遍。既然可以在 master 分支上修复 bug 后，在 dev 分支上可以“重放”这个修复过程，那么直接在 dev 分支上修复 bug，然后在 master 分支上“重放”行不行？当然可以，不过你仍然需要 git stash 命令保存现场，才能从 dev 分支切换到 master 分支。

Feature 分支#

操作和原理与 bug 分支类似，在这里就先不过多赘述了。后续有需要再进行补充。

多人协作#

当你从远程仓库克隆时，实际上 Git 自动把本地的 master 分支和远程的 master 分支对应起来了，并且，远程仓库的默认名称是origin。要查看远程库的信息，用 git remote 或者，用 git remote -v 显示更详细的信息，会显示可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支的命令很简单，在推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git push origin master   # 推送到 master 分支
$ git push origin dev      # 推送到 dev 分支

bash

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

master 分支是主分支，因此要时刻与远程同步；
dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug 分支只用于在本地修复 bug，就没必要推到远程了;
feature 分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之一个原则就是在 Git 中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

当你的小伙伴已经向 origin/dev 分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送（即现有远程版本与你的本地版本不一样，因为你们两个修改了同一个文件的，并且他先于你进行推送，导致你的校验失败），就可能出现如下这个问题。

$ git push origin dev
To github.com:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

bash

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git 已经提示我们，先用 git pull 把最新的提交从 origin/dev 抓下来，然后，在本地合并，解决冲突，再推送：

$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> dev

bash

git pull 也失败了，原因是没有指定本地 dev 分支与远程 origin/dev 分支的链接，根据提示，设置 dev 和 origin/dev 的链接：

$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

bash

再 pull：

$ git pull
Auto-merging env.txt
CONFLICT (add/add): Merge conflict in env.txt
Automatic merge failed; fix conflicts and then commit the result.

bash

这回 git pull 成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再 push：

$ git commit -m "fix env conflict"
[dev 57c53ab] fix env conflict

$ git push origin dev
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
   7a5e5dd..57c53ab  dev -> dev

bash

因此，多人协作的工作模式通常是这样：

首先，可以尝试用 git push origin <branch-name> 推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用 git pull 试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用 git push origin <branch-name> 推送就能成功！
如果 git pull提示 no tracking information ，则说明本地分支和远程分支的链接关系没有创建，用命令 git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

Rebase#

这个东西说实话我暂时没怎么明白，一个可预见的场景是代码改完了，到网页端检查一下，发现 README 没写好，就直接在网页上改了。这时本地远程不同步。本地下一次提交前就要先合并分支，再提交到远程。这是 commit 记录里就会多一条 merge 记录，看着很丑。有时候写完代码，前脚刚提交，后脚就发现 bug，有时候缝缝补补就出了好多个 commit。看着很丑，也不利于查看提交记录。就比如成为了下面这个样子。

$ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
*   e5e69f1 Merge branch 'dev'
|\  
| *   57c53ab (origin/dev, dev) fix env conflict
| |\  
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/  
* |   12a631b merged bug fix 101
|\ \  
| * | 4c805e2 fix bug 101
|/ /  
* |   e1e9c68 merge with no-ff
|\ \  
| |/  
| * f52c633 add merge
|/  
*   cf810e4 conflict fixed

bash

其实就是很乱不好看的问题，这个时候，rebase 就派上了用场。我们输入命令 git rebase 试试：

$ git rebase
First, rewinding head to replay your work on top of it...
Applying: add comment
Using index info to reconstruct a base tree...
M	hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree...
M	hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py

bash

输出了一大堆操作，到底是啥效果？再用 git log 看看：

$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello
...

bash

原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现 Git 把我们本地的提交“挪动”了位置，放到了 f005ed4 (origin/master) set exit=1 之后，这样，整个提交历史就成了一条直线。rebase 操作前后，最终的提交内容是一致的，但是，我们本地的 commit 修改内容已经变化了，它们的修改不再基于 d1be385 init hello，而是基于 f005ed4 (origin/master) set exit=1，但最后的提交 7e61ed4 内容是一致的。这就是 rebase 操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。最后，通过 push 操作把本地分支推送到远程。

~/learngit michael$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To github.com:michaelliao/learngit.git
   f005ed4..7e61ed4  master -> master

bash

再用 git log 看看效果，你会发现，远程分支的提交历史也是一条直线。

$ git log --graph --pretty=oneline --abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello
...

bash

还是有点不太理解，就写一个小结吧。

首先我们同步远程最新代码，开始工作…
git push 产生冲突，说明有人先你一步同步了他的本地代码到远程。
这时候，你需要先拉取代码，可以使用命令 git pull , 该命令会将远程的提交和你本地的提交 merge，如果有冲突需要手动解决并提交，会产生 merge 的记录。
git pull -- rebase 该命令会把你的提交“放置”在远程拉取的提交之后，即改变基础（变基），如果有冲突，解决所有冲突的文件，git add <冲突文件>。
git rebase --continue 完美解决问题。

后记#

这一篇的内容非常多，因为分支是 git 区别于其他版本管理软件的一个最显著的功能。所以你我，就常常复习，细细精进吧。