gitlabbash如何查看分支_大白话 git 教程-08-分支合并和典型用法

末蓝、 2022-10-27 01:48 351阅读 0赞

分支就是暂时从主线代码离开，去专注于开发一个新特性或者解决一个小 bug，git 创建和切换分支都能在瞬间完成，默认的 git 仓库，输入 git branch 可以看到只有一个 master 分支，通常这就是主分支。

wangbo@wangbo-VirtualBox:~/test/git-demo$ git branch* master

假设现在需要开发一个打印的新特功能，分支名称为 feature\_print，从 master 分支离开去新的分支有几个写法:

1. git branch feature\_print(或 git branch feature\_print master ) && git checkout feature\_print(或 git switch feature\_print)

2. git checkout -b feature\_print(或 git checkout -b feature\_print master)

3. git switch -c feature\_print (或 git switch -c feature\_print master)

其中 git switch 是新版本的 git 命令，以前的章节讲过 git checkout 用来恢复文件，checkout 本身是签出文件的意思，用来切换分支语义上有点模糊，后连就增加了语义更加明确的 switch 切换，随时都可以使用 git branch 查看分支的情况，前面的 \* 表示你当前所在的分支。

wangbo@wangbo-VirtualBox:~/test/git-demo$ git branch* feature_print  master

在新的分支下，可以专注于开发打印的功能了，我们添加一个 print.c 文件提交，从提交日志上看，工作成果是放到了 feature\_print 分支上。

![b6eef44a12429fa34d0b9d35c1d988bf.png][]

如果想知道两个分支的变化，可以使用 git diff 分支1 分支2，比如输入 git diff master feature\_print，由于我们当前就在 feature\_print 分支上，可以简化输入 git diff master 来和 master 分支相比较。

![38c8201734a4e377309be41520c4cbb9.png][]

可以非常清楚的看到了新增的打印相关的代码，假设打印的功能已经开发完成了，我们需要希望在主干分支上合并新的打印功能的代码，以便下一步的开发或是发布，首先切换到主分支:

1. git switch master

2. git checkout master

wangbo@wangbo-VirtualBox:~/test/git-demo$ git switch masterSwitched to branch 'master'wangbo@wangbo-VirtualBox:~/test/git-demo$ git branch  feature_print* master

git branch 命令清楚的显示当前已经在 master 主干分支了，现在需要将 feature\_print 分支的代码合并到 master 分支上，怎么做呢? 有 2 种做法，我们分别来介绍。

第一种: 使用 git merge 指令，默认如果执行 git merge feature\_print 就可以，但是这样不会为这次合并单独生成一个 commit 节点，为了以后能清楚的看到分支合并的情况，通常会使用一个参数 --no-ff，也就是使用 git merge --no-ff feature\_print 来执行。

![3ee35cf9d712b372e4be6091eb4b6b63.png][]

合并完成以后，提示消息如下:

wangbo@wangbo-VirtualBox:~/test/git-demo$ git merge --no-ff feature_printMerge made by the 'recursive' strategy. print.c | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 print.c

通过 tig 看看分支时间线的形态，可以清楚的看到了，master 分支合并了 feature\_print 分支的情况。

![59517112b360ed379d006e43438e0d3b.png][]

通常很多功能分支或者解决 bug 的分支，我们在合并完成以后，会将它删除，因为它的代码已经被合并到主分支了，以后需要继续开发或者有 bug 的话可以从主分支再次创建单独的分支来解决。使用 git branch -d feature\_print 来删除打印功能的分支，使用 tig 查看一下分支时间线的形态，发现feature\_print 分支这个名称不会再显示了，但是形态并没有变化，依靠提交的注释能够清楚的知道了合并了 feature\_print 分支的代码。

![86c6d5254a57d48d981924ced72b17bc.png][]

分支的时间线形态非常重要，尤其是我们需要回到历史的时候，实际工作的时候，可能同时有多个分支存在，如果合并后的时间线形态杂乱无章，对我们代码的维护会产生非常大的副作用。

上面是理想的 merge 合并的情况，处于 master 分支和 feature\_print 分支的代码完全是新增的包含关系，也就是没有修改到重叠的代码，如果合并feature\_print 分支的时候，master 分支上的打印功能也被修改了，那么合并就会产生冲突，而 git merge 会直接合并文件，并且报告冲突的代码情况，这时候需要手动修改文件解决冲突，完成后再次做一次提交。如下图，master 和 feature\_print 都同时修改了同一行代码，在 master 分支上查看区别:

![d2c4a5e698e7ebb072b32082293f04b3.png][]

执行 git merge --no-ff feature\_print 后显示:

![ce1b541c756bff22557ba7ad91eca367.png][]

提示有冲突尝试自动合并，但是自动合并失败了(如果没有修改到重叠的代码 git 可以自动化的成功合并)，需要手动解决文件的差异了，因为 git 并不知道保留哪个分支的代码才是需要保留的，打开文件发现长这个样子，用 === 分割了 2 个分支的代码，使用 <<<< 表示当前工作分支， >>>> 表示了被合并的 feature\_print 分支。

![b5f2df172306bfcf2a0a78c446d98ea8.png][]

我们觉得 master 分支添加的换行和 feature\_print 分支的 ok 文本都是需要保留的，修改文件如下:

![4df7d29e546d5fb9ef14406ec52e013a.png][]

使用 git status 查看一下仓库的状态:

wangbo@wangbo-VirtualBox:~/test/git-demo$ git statusOn branch masterYou have unmerged paths.  (fix conflicts and run "git commit")  (use "git merge --abort" to abort the merge)Unmerged paths:  (use "git add ..." to mark resolution)both modified:   print.cno changes added to commit (use "git add" and/or "git commit -a")

显示 print.c 的文件状态是 both modified，需要暂存提交，执行 git add . && git commit -m 'fix print text' 后使用 tig 查看分支形态:

![f3251d9f3cfd95e4de6b39109be475dc.png][]

所以 git merge 的缺点就是有冲突的时候，所有文件都被合并了，没有给用户留机会做出选择，并且单独生成了一个合并的 commit 提交节点(显示 M)。如果希望渐进式的合并，就需要使用第二种方法。

第二种: 使用 git rebase 命令，切换到 master 分支上，执行 git rebase feature\_print 合并，如果没有冲突，直接合并成功是最理想的情况，有冲突的情况如下:

![3e1349aaf50843e3c810bf4621d9648b.png][]

git 给了我们三种选择:

1. 自己解决文件冲突后执行 git rebase --continue 后继续尝试后面的合并

2. 执行 git rebase --skip 直接跳过后继续尝试合并，回头再来收拾残局

3. 执行 git rebase --abort 放弃本次合并，代码切换到 master 为合并前的状态

这时候我们可以打开文件 print.c，修复文件冲突，执行下面 2 个命令继续合并:

git add .git rebase --continue

continue 后 git 会继续尝试合并，如果还有文件冲突，重复执行这个过程，也可以随时 git rebase --abort 放弃，不想立刻解决就执行 git rebase --skip，直到整个合并完成。

wangbo@wangbo-VirtualBox:~/test/git-demo$ git statusrebase in progress; onto 5a8323aYou are currently rebasing branch 'master' on '5a8323a'.  (fix conflicts and then run "git rebase --continue")  (use "git rebase --skip" to skip this patch)  (use "git rebase --abort" to check out the original branch)Unmerged paths:  (use "git restore --staged ..." to unstage)  (use "git add ..." to mark resolution)both modified:   print.cno changes added to commit (use "git add" and/or "git commit -a")wangbo@wangbo-VirtualBox:~/test/git-demo$ git add .wangbo@wangbo-VirtualBox:~/test/git-demo$ git rebase --continueApplying: add blank line

执行完成以后我们看看分支的时间线形态:

![da3e5d4dd3562e53fc1ae1c7c19c6cd3.png][]

重点来了，我们发现 git rebase 和 git merge 生成的时间线并不相同，merge 保留了提交历史和操作过程，rebase 去掉了合并过程的提交更加简洁，但是合并后的 commit 信息可能需要修改，比如这个例子的 add blank line 已经不能同时表达文本被更新成 ok 的含义了，应该改为 fix print text 可能更合适(取决于你合并到底保留了什么样的代码)。

merge 和 rebase 如何选择呢?

1. 如果需要一个干净的时间线形态选择 rebase，如果希望渐进式的合并使用 rebase，可能会需要更新一次 commit 信息。

2. 如果需要保留完整的历史记录使用 merge，有多个文件冲突的时候可能比较棘手，但是 commit 信息都会保留下来。

关于 git 分支还有一些命令需要掌握:

1. 查看所有为合并的分支 git branch --no-merged

2. 查看合并过的分时 git branch --merged

3. 强行删除分支 git branch -D 分支名称

4. 而 git branch -v 可查看每个分支最后一次提交的情况

特别说明，一般我们不会在 master 分支上直接修改代码，本章节为了简化说明问题(避免太多的分支扰乱你的视线)，在 master 上直接修改了代码，第 12 节学习科学的分支开发模型，也就是如何更加合理规范的使用 git 分支。

[b6eef44a12429fa34d0b9d35c1d988bf.png]: /images/20221024/6a03260defbb4b49bc3d22bdf1b00202.png
[38c8201734a4e377309be41520c4cbb9.png]: /images/20221024/cbe97fbbd9074fe8aac4774c3d7ec959.png
[3ee35cf9d712b372e4be6091eb4b6b63.png]: /images/20221024/4f7963fc90fd4397a9364bd05581522b.png
[59517112b360ed379d006e43438e0d3b.png]: /images/20221024/5e2cbfdcb6d043a4942c5bbbec49b725.png
[86c6d5254a57d48d981924ced72b17bc.png]: /images/20221024/4167fb5b945743f88faa8275dc9cd733.png
[d2c4a5e698e7ebb072b32082293f04b3.png]: /images/20221024/cd11def9d1ec4fdf87baee2feb014bb5.png
[ce1b541c756bff22557ba7ad91eca367.png]: /images/20221024/8bbec168b73f42fe826ff3b6f13084e3.png
[b5f2df172306bfcf2a0a78c446d98ea8.png]: /images/20221024/b3a83399281c4b68b3fbe3b869071c6c.png
[4df7d29e546d5fb9ef14406ec52e013a.png]: /images/20221024/343e4e1853534796914208306263a171.png
[f3251d9f3cfd95e4de6b39109be475dc.png]: /images/20221024/7db1dd8b9f334c2a9113137a0f3e7f45.png
[3e1349aaf50843e3c810bf4621d9648b.png]: /images/20221024/80930bec7f0348a49c4f1e2ebea0b3e5.png
[da3e5d4dd3562e53fc1ae1c7c19c6cd3.png]: /images/20221024/67755005db8545f1a6bf8692acecdfe3.png