当前位置：首页 > news >正文

Git 分支管理与多人协作实战指南

news 来源：原创 2025/6/7 18:03:50

1.分支管理：

1.1.理解分支：

1.2.创建分支

1.3.切换分支

1.4.合并分支

1.5.删除分支

2.合并冲突

3.分支管理策略

分支策略

4.bug分支

5.删除临时分支

git branch -d 和 git branch -D的区别

6.多人协作

6.1.多人协作一

6.2.多人协作二

1.分支管理：

1.1.理解分支：

本章开始介绍 Git 的杀手级功能:分支。

分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习 C++的时候，另一个你正在另一个平行宇宙里努力学习 JAVA。
如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并
了，结果，你既学会了 C++ 又学会了 JAVA!

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就可以理解为是一个分支。

截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即 master分支。
再来理解一下HEAD，HEAD 严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD 指向的就是当前分支。

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

1.2.创建分支

Git 支持我们查看或创建其他分支，在这里我们来创建第一个自己的分支 dev ，对应的命令为:

git branch #查看当前本地所有分⽀
* master
git branch dev #新建分⽀dev
git branch
dev
* master

当我们创建新的分支后，Git新建了⼀个指针叫dev， * 表示当前 HEAD 指向的分支是 master 分分支。

一张图总结：

1.3.切换分支

那如何切换到 dev 分支下进行开发呢?使用git checkout 命令即可完成切换，示例如下:

git checkout dev
Switched to branch 'dev'
git branch
* devmaster

我们发现 HEAD 已经指向了 dev，就表示我们已经成功的切换到了 dev 上!
接下来，在 dev 分支下修改 ReadMe 文件，新增一行内容，并进行一次提交操作。

我们观察到的现象如下：

当切回master分支之后，我们就会发现在master分支上ReadMe文件并没有做任何改变！再切换回dev分支后发现文件内容改变了，这是为什么呢？

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

当切换到 master 分支之时，HEAD 就指向了 master，当然看不到提交了!

1.4.合并分支

为了在 master 主分支上能看到新的提交，就需要将 dev 分支合并到 master 分支，示例如下!

git branch 
* devmaster
git checkout master # 切换到 master 上进⾏合并
Switched to branch 'master'
git merge dev # 合并 dev 分⽀ 
Updating 16623e1..3740dce
Fast-forwardReadMe | 1 +1 file changed, 1 insertion(+)

git merge dev

git merge 命令用于合并指定分支到当前分支。合并后，master 就能看到 dev分支提交的内容
了。此时的状态如图如下所示。

Fast-forward 代表“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能 Fast-forward，我们后面会讲其他方式的合并。

1.5.删除分支

合并完成后,dev分支对于我们来说就没用了，那么dev分支就可以被删除掉，注意如果当前正处于某分支下，就不能删除当前分支，如:

hyb@139-159-150-152:~/gitcode$ git branch
* devmaster
hyb@139-159-150-152:~/gitcode$ git branch -d dev 
error: Cannot delete branch 'dev' checked out at '/home/hyb/gitcode'

而可以在其他分支下删除当前分支，如：

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git branch -d dev 
Deleted branch dev (was bdaf528).
hyb@139-159-150-152:~/gitcode$ git branch
* master

此时的状态图如下：

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

2.合并冲突

可是，在实际分支合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。
为了演示这问题，创建一个新的分支 dev1 ，并切换至目标分支，我们可以使用 git checkout -b dev 一步完成创建并切换的动作

在 dev1 分支下修改 ReadMe文件，更改文件内容如下，并进行⼀次提交，如：

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch # 将 aaa 该为 bbb
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev1 0854245] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)

切换至master分支，并观察文件的内容

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write aaa for new branch

我们发现，切回来之后，文件内容由变成了老的版本，这种现象很正常，我们现在也完全能理解。
此时在 master分支上，我们对 ReadMe文件再进行一次修改，并进行提交，如下:

hyb@139-159-150-152:~/gitcode$ git branch dev1
* master
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write ccc for new branch 
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[master c10f6d0] modify ReadMe1 file changed, 1 insertion(+), 1 deletion(-)

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

这种情况下，Git 只能试图把各自的修改合并起来，但这种合并就可能会有冲突，如下所示:

hyb@139-159-150-152:~/gitcode$ git merge dev1 
Auto-merging ReadMe
CONFLICT (content): Merge conflict in ReadMe
Automatic merge failed; fix conflicts and then commit the result.
hyb@139-159-150-152:~/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 会⽤ <<<<<< , ======, >>>>>> 来标记出不同分支的冲突内容，如下所⽰：

hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
<<<<<<< HEAD
write ccc for new branch 
=======
write bbb for new branch 
>>>>>>> dev1

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

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

最后不要忘记了dev分支使用完毕了，直接删除。

3.分支管理策略

通常合并分支时，如果可能，Git会采用 Fast forward 模式。还记得如果我们采用 Fast forward 模式之后，形成的合并结果是什么呢?回顾一下

在这种 Fast forward 模式下，删除分支后，查看分支历史时，会丢掉分支信息，看不出来最新提
交到底是 merge 进来的还是正常提交的。
但在合并冲突部分，我们也看到通过解决冲突问题，会再进行一次新的提交，得到的最终状态为:

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

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 2976afc (HEAD -> master) merge ReadMe
|\ 
| * c594fd1 modify ReadMe
* | c10f6d0 modify ReadMe
|/

Git 支持我们强制禁用 Fast forward 模式，那么就会在 merge 时生成一个新的 commit ，这样
从分支历史上就可以看出分支信息。
下面我们实战-下 --no-ff 方式的 git merge 。

git merge --no-ff -m "merge with no-ff" dev2

hyb@139-159-150-152:~/gitcode$ git checkout master 
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git merge --no-ff -m "merge with no-ff" dev2
Merge made by the 'recursive' strategy.ReadMe | 1 +1 file changed, 1 insertion(+)

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

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

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

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理:
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活;
那在哪干活呢?干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样:

4.bug分支

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

为什么无法提交呢？

如果当前分支有数据没有提交的话，是切换不了分支的。

你的工作区有未提交的更改。如果你此时切换分支（例如切换到 master 分支来修复 bug），Git 会阻止你切换分支，因为这些未提交的更改可能会与目标分支的文件冲突.

hyb@139-159-150-152:~/gitcode$ git branch 
* dev2master
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d
i am coding ...
hyb@139-159-150-152:~/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")

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

git stash注意需要在dev分支下进行.

用 git status 查看工作区，就是干净的(除非有没有被 Git 管理的文件)，因此可以放心地创建分
支来修复bug。
储藏 dev2 工作区之后，由于我们要基于master分支修复 bug，所以需要切回 master 分支，再新
建临时分支来修复 bug，示例如下:

hyb@139-159-150-152:~/gitcode$ git checkout master # 切回master
Switched to branch 'master'
hyb@139-159-150-152:~/gitcode$ git checkout -b fix_bug # 新建并切换到 fix_bug 分
⽀
Switched to a new branch 'fix_bug'
hyb@139-159-150-152:~/gitcode$ vim ReadMe 
hyb@139-159-150-152:~/gitcode$ cat ReadMe 
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
a,b,c,d,e # 修复bug--忘记写e
hyb@139-159-150-152:~/gitcode$ git add ReadMe # 重新add，commit
hyb@139-159-150-152:~/gitcode$ git commit -m"fix bug"
[fix_bug 4bbc0c4] fix bug1 file changed, 1 insertion(+), 1 deletion(-)

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

⾄此，bug的修复⼯作已经做完了，我们还要继续回到dev2 分⽀进⾏开发。切换回 dev2 分支：

⼯作区是⼲净的，刚才的⼯作现场存到哪去了？⽤ git stash list 命令看看：

hyb@139-159-150-152:~/gitcode$ git stash list
stash@{0}: WIP on dev2: 41b082f modify ReadMe

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

hyb@139-159-150-152:~/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} (4f873250b3503687b5efd26196776aee7e3724c2)

再次查看的时候，我们就发现没有现场可以恢复了

另外，恢复现场也可以采用 git stash apply 恢复，但是恢复后，stash内容并不删除，你需要
用 git stash drop 来删除;

恢复完代码之后我们便可以继续完成开发，开发完成后便可以进行提交。

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

Master 分支目前最新的提交，是要领先于新建 dev2 时基于的 master 分支的提交的，所以我们
在 dev2 中当然看不见修复 bug 的相关代码。
我们的最终目的是要让 master 合并 dev2 分支的，那么正常情况下我们切回 master 分支直接合
并即可，但这样其实是有一定风险的。
是因为在合并分支时可能会有冲突，而代码冲突需要我们手动解决(在 master 上解决)。我们无法
保证对于冲突问题可以正确地一次性解决掉，因为在实际的项目中，代码冲突不只一两行那么简单，有可能几十上百行，甚至更多，解决的过程中难免手误出错，导致错误的代码被合并到 master 上。
此时的状态为:

解决这个问题的一个好的建议就是:最好在自己的分支上合并下 master ，再让 master 去合并
dev ，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响 master 。此时的状态
为，

5.删除临时分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个分支，我们可以将其称之为 feature 分支，在上面开发，完成后，合并，最
后，删除该 feature 分支。
可是，如果我们今天正在某个 feature 分支上开发了一半，被产品经理突然叫停，说是要停止新功
能的开发。虽然白干了，但是这个 feature 分支还是必须就地销毁，留着无用了。这时使用传统
的 git branch -d 命令删除分支的方法是不行的。

git branch -d 和 git branch -D的区别

使用 git branch -d <branch-name> 时，Git 会检查分支的合并状态，如果分支尚未合并，则拒绝删除并给出警告。
使用 git branch -D <branch-name> 时，Git 不会检查分支的合并状态，会直接强制删除分支。

因此，在删除分支之前，最好确认该分支的合并状态，以避免意外丢失尚未合并的工作。如果不确定分支的合并状态，可以先使用 git merge 命令合并分支，或者使用 git branch -vv 查看分支的详细信息。

6.多人协作

目前，我们所完成的工作如下:

基本完成 Git 的所有本地库的相关操作，git基本操作，分支理解，版本回退，冲突解决等等
申请码云账号，将远端信息clone到本地，以及推送和拉取。

是时候干最重要的一件事情了，实现多人协作开发!

6.1.多人协作一

这里我们的情况是多人在同一条分支上进行协作。

总结一下，在同一分支下进行多人协作的工作模式通常是这样:

首先，可以试图用 git push origin branch-name 推送自己的修改;
如果推送失败，则因为远程分支比你的本地更新，需要先用 git pull 试图合并;
如果合并有冲突，则解决冲突，并在本地提交;
没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功!
功能开发完毕，将分支 merge 进 master，最后删除分支。

我们使用git pull命令将远程的dev分支拉取到本地的分支，但本地分支不能直接对这个远程的dev分支进行操作，因此还需要使用git checkout -b dev origin/dev 会将本地分⽀和远程分⽀的进⾏关系链接。将本地的dev对远程的dev进行一个跟踪

使用git branch -vv 选项查看我们分支的跟踪情况。

git checkout -b [dev] [origin/dev]后面跟上origin远程链接，这样我们push的时候可以直接使用git push命令，不需要再加入其他的参数 origin 和master

6.2.多人协作二

一般情况下，如果有多需求需要多人同时进行开发，是不会在一个分支上进行多人开发，而是一个需求或一个功能点就要创建一个 feature 分支。
现在同时有两个需求需要你和你的小伙伴进行开发，那么你们俩便可以各自创建一个分支来完成自己的工作。

在上个部分我们已经了解了可以从码云上直接创建远程分支，其实在本地创建的分支也可以通过推送的方式发送到远端。在这个部分我们就来用一下这种方式。

# 新增本地分⽀ feature-1 并切换
hyb@139-159-150-152:~/git_teaching$ git branch dev
* master
hyb@139-159-150-152:~/git_teaching$ git checkout -b feature-1
Switched to a new branch 'feature-1'
# 新增需求内容-创建function1⽂件
hyb@139-159-150-152:~/git_teaching$ vim function1
hyb@139-159-150-152:~/git_teaching$ cat function1 
Done!
# 将 feature-1 分⽀推送到远端
hyb@139-159-150-152:~/git_teaching$ git add function1 
hyb@139-159-150-152:~/git_teaching$ git commit -m"add function1"
[feature-1 12ed0db] add function11 file changed, 1 insertion(+)create mode 100644 function1
hyb@139-159-150-152:~/git_teaching$ git push origin feature-1 
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 270 bytes | 270.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Powered by GITEE.COM [GNK-6.4]
remote: Create a pull request for 'feature-1' on Gitee by visiting:
remote: https://gitee.com/hyb91/git_teaching/pull/new/hyb91:feature1...hyb91:master
Togitee.com:hyb91/git_teaching.git* [new branch] feature-1 -> feature-1

对于小伙伴来说，可以进行以下的操作：

此时，在本地，你看不见他新建的文档，他看不见你新建的文档。并且推送各自的分支时，并没有任何冲突，你俩互不影响，用起来很舒服!!

正常情况下，你俩就可以在自己的分支上进行专业的开发了!
但天有不测风云，你的小伙伴突然生病了，但需求还没开发完，需要你帮他继续开发，于是他便把
feature-2分支名告诉你了。这时你就需要在自己的机器上切换到 feature-2分支帮忙继续开发，要做的操作如下:

# 必须先拉取远端仓库内容
hyb@139-159-150-152:~/git_teaching$ git pull
...
From gitee.com:hyb91/git_teaching305f78a..72c5345 dev -> origin/dev* [new branch] feature-2 -> origin/feature-2
# 可以看到远程已经有了feature-2
hyb@139-159-150-152:~/git_teaching$ git branch -adev
* feature-1masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master# 切换到feature-2分⽀上，可以和远程的feature-2分⽀关联起来，
# 否则将来只使⽤ git push 推送内容会失败
hyb@139-159-150-152:~/git_teaching$ git checkout -b feature-2 origin/feature-2
Branch 'feature-2' set up to track remote branch 'feature-2' from 'origin'.
Switched to a new branch 'feature-2'
hyb@139-159-150-152:~/git_teaching$ ls
a.so b.ini file.txt function2 README.en.md README.md

切换成功后，便可以看见feature-2分⽀中的function2文件了，接着就可以帮⼩伙伴进⾏开发，然后进行推送。

这时，你的小伙伴已经修养的差不多，可以继续进行自己的开发工作，那么他首先要获取到你帮他开发的内容，然后接着你的代码继续开发。或者你已经帮他开发完了，那他也需要在自己的电脑上看看你帮他写的代码: