如何克服解决Git冲突的恐惧症?(Git分支策略)

2018 年 7 月 11 日 前端黑板报

git默认的是master分支,试想下,如果所有的开发都在master分支,想起来都比较混乱,那么有没有比较科学的分支策略呢?本篇将介绍git的分支策略,听我慢慢道来~

分支分类

正常分支:

  • master:主分支

  • develop:开发分支


临时分支:

  • feature:功能分支

  • release:预发布分支

  • fixbug:修补bug分支

主分支

首先,代码库应该有一个、且仅有一个主分支。

所有提供给用户使用的正式版本,都在这个主分支上发布。

Git主分支的名字,默认叫做Master。

它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。

Git高手之路

作者:[波兰]雅各布·纳热布斯基(Jakub Nar?bski )

当当 广告
购买

Git团队协作

作者:[加] 艾玛?简?霍格宾?韦斯特比(Emma Jane Hogbin Westb

当当 广告
购买

开发分支

主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。

这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行”合并”(merge)。

Git创建Develop分支的命令:

git checkout -b develop master

将Develop分支发布到Master分支的命令:

# 切换到Master分支
git checkout master
# 对Develop分支进行合并
git merge --no-ff develop

功能分支

功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。

功能分支的名字,可以采用feature-*的形式命名。

Git创建一个功能分支:

git checkout -b feature-x develop

开发完成后,将功能分支合并到develop分支:

git checkout develop
git merge --no-ff feature-x

删除feature分支:

git branch -d feature-x

预发布分支

预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。

它的命名,可以采用release-*的形式。

Git创建一个预发布分支:

git checkout -b release-1.2 develop

确认没有问题后,合并到master分支:

git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点,做一个标签 git tag -a 1.2

再合并到develop分支:

git checkout develop
git merge --no-ff release-1.2

最后,删除预发布分支:

git branch -d release-1.2

修补bug分支

软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。

Git创建一个修补bug分支:

git checkout -b fixbug-0.1 master

修补结束后,合并到master分支:

git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1

再合并到develop分支:

git checkout develop
git merge --no-ff fixbug-0.1

最后,删除”修补bug分支”:

git branch -d fixbug-0.1

多人协作的工作模式

首先,可以试图用git push origin branch-name推送自己的修改;

如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;

如果合并有冲突,则解决冲突,并在本地提交;

没有冲突或者解决掉冲突后,再用git push origin branch-name推送就能成功!

如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch —set-upstream branch-name origin/branch-name。


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


登录查看更多
0

相关内容

Git 是一个为了更好地管理 Linux 内核开发而创立的分布式版本控制和软件配置管理软件。 国内外知名 Git 代码托管网站有: GitHub.com Coding.net code.csdn.net ...
干净的数据:数据清洗入门与实践,204页pdf
专知会员服务
160+阅读 · 2020年5月14日
专知会员服务
31+阅读 · 2020年4月24日
【Nature论文】深度网络中的梯度下降复杂度控制
专知会员服务
38+阅读 · 2020年3月9日
【学科交叉】抗生素发现的深度学习方法
专知会员服务
23+阅读 · 2020年2月23日
专知会员服务
35+阅读 · 2019年12月13日
目标检测中边界框的回归策略
极市平台
17+阅读 · 2019年9月8日
重磅:git checkout 未来将消失
Python程序员
15+阅读 · 2019年8月22日
用 GitLab 的 Merge Request 做代码评审
DevOps时代
4+阅读 · 2019年5月5日
使用 C# 和 Blazor 进行全栈开发
DotNet
6+阅读 · 2019年4月15日
.NET Core 环境下构建强大且易用的规则引擎
优化哈希策略
ImportNew
5+阅读 · 2018年1月17日
情感分析:数据采集与词向量构造方法
北京思腾合力科技有限公司
29+阅读 · 2017年12月20日
教程 | 基于遗传算法的拼图游戏解决方案
机器之心
109+阅读 · 2017年11月12日
Arxiv
99+阅读 · 2020年3月4日
Arxiv
7+阅读 · 2018年12月5日
Arxiv
7+阅读 · 2018年1月24日
VIP会员
相关资讯
目标检测中边界框的回归策略
极市平台
17+阅读 · 2019年9月8日
重磅:git checkout 未来将消失
Python程序员
15+阅读 · 2019年8月22日
用 GitLab 的 Merge Request 做代码评审
DevOps时代
4+阅读 · 2019年5月5日
使用 C# 和 Blazor 进行全栈开发
DotNet
6+阅读 · 2019年4月15日
.NET Core 环境下构建强大且易用的规则引擎
优化哈希策略
ImportNew
5+阅读 · 2018年1月17日
情感分析:数据采集与词向量构造方法
北京思腾合力科技有限公司
29+阅读 · 2017年12月20日
教程 | 基于遗传算法的拼图游戏解决方案
机器之心
109+阅读 · 2017年11月12日
Top
微信扫码咨询专知VIP会员