〔Part2〕Git进阶教程：分支（branch、checkout、merge、-b、-d、fast-forward、ff、--no-ff、bug）_git checkout branch

6. 分支管理

6.1 分支的介绍

分支就像是科幻电影中的平行宇宙一样。当我们专注于在电脑前努力学习 Git 的同时，另一个版本的我们则努力学习着 Deep Learning，仿佛存在于另一个平行宇宙中。这两个平行宇宙互不干扰，对我们当前的现实生活也没有什么实质性影响。然而，在某个时间点，这两个平行宇宙合并了，结果是我们既学会了 Git，又学会了 Deep Learning！

那么在实际应用中，分支有什么作用呢？假设我们计划开发一个新的功能，但需要花费两周的时间来完成。在第一周，我们完成了 50% 的代码编写工作。如果立即将这些代码提交，由于代码尚未完整，其他人将无法继续工作。然而，如果等到所有代码都完成后再进行一次性提交，这样做可能会面临丢失每天进展的巨大风险。

现在有了分支，我们就不必担心了。我们可以创建一个属于自己的分支，其他人看不到，而他们可以继续在原有的分支上进行正常工作。而我们则可以在自己的分支上进行开发，按照进度自由提交代码。直到开发完毕后，再将我们的分支一次性合并到原有分支中。这样既保证了安全性，又不会影响其他人的工作进程。

6.2 创建和融合分支

Git 将我们以前每次提交的版本串联成一条时间线，这条时间线就是一个分支。目前，我们只有一条时间线，在 Git 中称为主分支，即 main 分支。严格来说，HEAD 并不指向提交本身，而是指向 main 分支，而 main 分支才是指向提交的。因此，HEAD 指向的是当前的分支。

main 分支等价于 master 分支

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

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

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

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

dev: develop，开发

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

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

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

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

6.3 例子

执行如下命令可以查看当前有几个分支并且看到在哪个分支下工作。

git branch
1

下面创建一个 dev 分支并切换到其上进行工作。

git checkout -b dev
1

其中，-b 表示创建分支。

---

Question：介绍一下 Git 中的 checkout。

Answer：在 Git 中，checkout 用于切换到不同的分支或恢复文件的状态。它有几个常见的用途：

• 切换分支：使用 git checkout <branch> 可以切换到指定的分支，将HEAD指向该分支，并更新工作目录中的文件以反映该分支的内容。
• 恢复文件：使用 git checkout -- <file> 可以将指定文件恢复到最近一次提交的状态，丢弃在工作目录中对文件的修改。
• 创建分支：使用 git checkout -b <new-branch> 可以创建一个新分支并切换到该分支。

总结来说，checkout 用于切换分支、恢复文件或创建分支，而 commit 用于将更改保存为提交。

---

下面我们修改 code.py 内容，在里面添加一行，并进行提交。

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

git checkout main
1

⚠️ 注意：不要加 -b，因为 -b 表示创建分支，我们的 main 分支是存在的。如果添加了 -b，那么会发生语法错误。

查看 code.py，发现添加的内容没有了。因为那个提交是在 dev 分支上，而 main 分支此刻的提交点并没有变：

现在，我们把 dev 分支的工作成果合并到 main 分支上：

git merge dev
1

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

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

合并完成后，就可以放心地删除 dev 分支了，删除后查看 branch，就只剩下 main 分支了。

git branch -d dev
1

-d: delete

总结:

6.4 解决冲突

合并分支往往也不是一帆风顺的。我们举个例子：

1. 创建一个新分支 dev。
2. 修改 code.py 内容，并进行提交。
3. 切换回 main 分支
4. 在 main 的 code.py 添加一行内容并进行提交。

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

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

执行如下命令尝试将 dev 分支合并到 main 分支上来。

Git 告诉我们，code.py 文件存在冲突，必须手动解决冲突后再提交。

使用 git status 命令也可以告诉我们冲突的文件：

查看 code.py 的内容:

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

我们再次提交：

现在，main 分支和 dev 分支变成了下图所示：

用带参数的 git log 也可以看到分支的合并情况：

最后工作完成，可以删除 dev 分支。

总结:

• 出现冲突的原因：在两个分支上都有了提交且都编辑了同一个文件

6.5 管理分支的策略

通常，在合并分支时，如果可能的话，Git 会使用快进（fast-forward）模式。但有时快进合并无法成功，尽管合并过程中没有冲突。在这种情况下，Git 将执行一次新的提交来完成合并。然而，需要注意的是，在这种模式下，删除分支后将丢失分支的信息。

1. 创建切换到 dev 分支下。

git checkout -b dev
1

2. 新建一个文件 code3.py 编辑内容如下，并提交一个commit。

# 创建文件
touch code3.py

# 使用 gedit 编辑文件
gedit code3.py

# 查看文件内容
cat code3.py

# add
git add code3.py

# commit
git commit -m "dev create & modifies code.py"
1
2
3
4
5
6
7
8
9
10
11
12
13
14

3. 切换回 main 分支，编辑 code.py 并进行一个提交。

# 切换分支（不要加 -b）
git checkout main

# 编辑文件
gedit code.py

# add
git add code.py

# commit
git commit -m "main add a new line in code.py"
1
2
3
4
5
6
7
8
9
10
11

3. 合并 dev 分支的内容到 main 分支。

git merge dev
1

出现如下提示，这是因为这次不能进行快速合并(虽然没有冲突)，所以 Git 提示输入合并说明信息，输入之后合并内容之后 Git 会自动创建一次新的提交。

此时，写入说明信息后就完成合并了。

我们使用分支命令查看分支信息。

git log --pretty=oneline
1

当合并完毕后，我们可以删除 dev 分支：

git branch -d dev
1

声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop博客】