当前位置:   article > 正文

【Git企业开发】第四节.Git的分支管理策略和bug分支_git 生产分支 开发分支 bug分支如何管理

git 生产分支 开发分支 bug分支如何管理

文章目录

  • 前言
  • 一、Git的分支管理策略
  •       1.1 Fast forward 模式和--no-ff 模式
  •       1.2 企业分支管理策略
  • 二、bug分支
  • 三、删除临时分支
  • 四、总结
  • 总结


前言


一、Git的分支管理策略

1.1 Fast forward 模式和--no-ff 模式

通常合并分支时,如果可能,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 。

步骤一: 首先,创建新的分支 dev2 ,并切换至新的分支:
代码示例:
hyb@139-159-150-152:~/gitcode$ git checkout -b dev2               #切换到分支dev2
Switched to a new branch 'dev2'

步骤二:修改 ReadMe 文件,并提交一个新的 commit :
代码示例:
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                                                                      #修改文件信息
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 41b082f] modify ReadMe
1 file changed, 1 insertion(+)

 步骤三:切回 master 分支,通过开始--no-ff 方式合并

代码示例:

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(+)
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
注意 --no-ff 参数,表示禁用 Fast forward 模式。禁用 Fast forward 模式后合并会创建
一个新的 commit ,所以加上 -m 参数,把描述写进去。

步骤四:合并后,查看分支历史

代码示例:

hyb@139-159-150-152:~/gitcode$ git log --graph --pretty=oneline --abbrev-commit
* 5bd16b4 (HEAD -> master) merge with no-ff
|\
| * 41b082f (dev2) modify ReadMe
|/
可以看到,不使用 Fast forward 模式,merge后就像这样:
图示示例:

总结:

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

1.2 企业分支管理策略

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

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

那在哪⼲活呢?


干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如1.0版本发布
时,再把dev分支合并到master上,在master分支发布1.0版本;
你和你的小伙伴们每个人都在dev分支上干活,每个人都有自己的分支,时不时地往dev分支上合并就可以了。
图示示例:
所以,团队合作的分支看起来就像这样:

二、bug分支

假如我们现在正在 dev2 分支上进行开发,开发到一半,突然发现 master 分支上面有 bug,需要解决。
在Git中,每个 bug 都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。

可现在 dev2 的代码在工作区中开发了一半,还无法提交,怎么办?
代码示例:
hyb@139-159-150-152:~/gitcode$ git branch
* dev2
master
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 ...                                          #dev2 的代码在工作区中开发了一半
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 命令可以将当前的⼯作区信息进⾏储藏,被储藏的内容可以在将来某个时间恢复出来。
代码示例:
hyb@139-159-150-152:~/gitcode$ git stash
Saved working directory and index state WIP on dev2: 41b082f modify ReadMe
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean
用 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 bug
1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后,切换到 master 分支,并完成合并,最后删除 fix_bug 分支:
代码示例:
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 fix_bug branch" fix_bu
Merge made by the 'recursive' strategy.
ReadMe | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
hyb@139-159-150-152:~/gitcode$ git branch -d fix_bug
Deleted branch fix_bug (was 4bbc0c4).

至此,bug 的修复工作已经做完了,我们还要继续回到 dev2 分支进行开发。切换回 dev2 分支:
代码示例:
hyb@139-159-150-152:~/gitcode$ git checkout dev2
Switched to branch 'dev2'
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean

工作区是干净的,刚才的工作现场存到哪去了?

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

再次查看的时候,我们已经发现已经没有现场可以恢复了
代码示例:
hyb@139-159-150-152:~/gitcode$ git stash list
hyb@139-159-150-152:~/gitcode$

另外,恢复现场也可以采用 git stash apply 恢复,但是恢复后,stash内容并不删除,你需要 用 git stash drop 来删除;
你可以多次stash,恢复的时候,先用  git stash list 查看,然后恢复指定的stash,用命令
git stash apply stash@{0} ,这部分请同学们自行使用。

恢复完代码之后我们便可以继续完成开发,开发完成后便可以进行提交:
代码例如:
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 ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe"
[dev2 ed0916d] modify ReadMe
1 file changed, 1 insertion(+)

但我们注意到了,修复 bug 的内容,并没有在 dev2 上显示。 此时的状态图为:
Master 分支目前最新的提交,是要领先于新建 dev2 时基于的 master 分支的提交的,所以我们在 dev2 中当然看不见修复 bug 的相关代码。

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

解决这个问题的⼀个好的建议就是:
最好在自己的分支上合并下 master ,再让 master 去合并dev ,这样做的目的是有冲突可以在本地分支解决并进行测试,而不影响 master 。
此时的状态图为:
第一步:
第二步:
注意:
对应的实操演示如下,要说明的是,以下演示的merge操作,没有使用 --no-ff ,但上述的图示是禁用 Fast forward 了模式后得出的,主要是为了方便解释问题。

代码示例:

# dev 合并 master
hyb@139-159-150-152:~/gitcode$ git branch
* dev2
master
hyb@139-159-150-152:~/gitcode$ git merge master
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$ cat ReadMe
hello bit
hello git
hello world
hello version1
hello version2
hello version3
write bbb for new branch
<<<<<<< HEAD
a,b,c,d
i am coding ... Done!
=======
a,b,c,d,e
>>>>>>> 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 bbb for new branch
a,b,c,d,e
i am coding ... Done!
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"merge master"
[dev2 447d29f] merge master
hyb@139-159-150-152:~/gitcode$ git status
On branch dev2
nothing to commit, working tree clean
# 切回master
hyb@139-159-150-152:~/gitcode$ git checkout master
Switched to branch 'master'
# master 合并 dev2---⽆需解决冲突!!
hyb@139-159-150-152:~/gitcode$ git merge dev2
Updating 193421f..447d29f
Fast-forward
ReadMe | 1 +
1 file changed, 1 insertion(+)
hyb@139-159-150-152:~/gitcode$ git status
On branch master
nothing to commit, working tree clean
# 删除 dev2 分⽀
hyb@139-159-150-152:~/gitcode$ git branch -d dev2
Deleted branch dev2 (was 447d29f).

三、删除临时分支

软件开发中,总有⽆穷⽆尽的新的功能要不断添加进来。
添加⼀个新功能时,你肯定不希望因为⼀些实验性质的代码,把主分⽀搞乱了,所以,每添加⼀个新功能,最好新建⼀个分⽀,我们可以将其称之为 feature 分⽀,在上⾯开发,完成后,合并,最后,删除该 feature 分⽀。

可是,如果我们今天正在某个 feature 分⽀上开发了⼀半,被产品经理突然叫停,说是要停⽌新功能的开发。虽然⽩⼲了,但是这个 feature 分⽀还是必须就地销毁,留着⽆⽤了。这时使⽤传统的 git branch -d 命令删除分⽀的⽅法是不⾏的。
演⽰如下:
# 新增并切换到 dev3 分支
hyb@139-159-150-152:~/gitcode$ git checkout -b dev3
Switched to a new branch 'dev3'
# 开始开发新功能并提交
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
i am coding ... Done!
i am writing new features ...
hyb@139-159-150-152:~/gitcode$ git add .
hyb@139-159-150-152:~/gitcode$ git commit -m"modify ReadMe for new features"
[dev3 cd2f149] modify ReadMe for new features
1 file changed, 1 insertion(+)
# 此时新功能叫停
# 切回master准备删除dev3
hyb@139-159-150-152:~/gitcode$ git checkout master
Switched to branch 'master'
# 常规删除dev3分支时失败
hyb@139-159-150-152:~/gitcode$ git branch -d dev3
error: The branch 'dev3' is not fully merged.
If you are sure you want to delete it, run 'git branch -D dev3'.

直接使用传统的删除分支的方法不行,按照提示,有了如下方式:
代码示例:
hyb@139-159-150-152:~/gitcode$ git branch -D dev3
Deleted branch dev3 (was cd2f149).
hyb@139-159-150-152:~/gitcode$ git branch
* master

四、总结

gitee分支的作用:

分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
并且Git无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。


总结

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/知新_RL/article/detail/1009483
推荐阅读
相关标签
  

闽ICP备14008679号