git 开发分支图解

　　Git，在技术层面上，绝对是一个无中心的分布式版本控制系统，但在管理层面上，我建议你保持一个中心版本库。

　　我建议，一个中心版本库(我们叫它origin)至少包括两个分支，即“主分支(master)”和“开发分支(develop)”

　　要确保：团队成员从主分支(master)获得的都是处于可发布状态的代码，而从开发分支(develop)应该总能够获得最新开发进展的代码。

　　在一个团队开发协作中，我建议，要有“辅助分支”的概念。

　　“辅助分支”，大体包括如下几类：“管理功能开发”的分支、“帮助构建可发布代码”的分支、“可以便捷的修复发布版本关键BUG”的分支，等等。

　　“辅助分支”的最大特点就是“生命周期十分有限”，完成使命后即可被清除。

　　我建议至少还应设置三类“辅助分支”，我们称之为“Feature branches”，“Release branches”，“Hotfix branches”。

　　至此，我们形成了如下这张最重要的组织组，包含了两个粗体字分支（master/develop）和三个细体字分支（feature/release/hotfixes）。

　　“Feature branches”，起源于develop分支，最终也会归于develop分支。

　　“Feature branches”常用于开发一个独立的新功能，且其最终的结局必然只有两个，其一是合并入“develop”分支，其二是被抛弃。最典型的“Fearture branches”一定是存在于团队开发者那里，而不应该是“中心版本库”中。

　　“Feature branches”起源于“develop”分支，实现方法是：

git checkout -b myfeature develop

　　“Feature branches”最终也归于“develop”分支，实现方式是：

git checkout devleop

git merge --no-ff myfeature

（--no-ff，即not fast forward，其作用是：要求git merge即使在fast forward条件下也要产生一个新的merge commit）（此处，要求采用--no-ff的方式进行分支合并，其目的在于，希望保持原有“Feature branches”整个提交链的完整性）

git branch -d myfeature

git push origin develop

　　“Release branch”，起源于develop分支，最终归于“develop”或“master”分支。这类分支建议命名为“release-*”

　　“Relase branch”通常负责“短期的发布前准备工作”、“小bug的修复工作”、“版本号等元信息的准备工作”。与此同时，“develop”分支又可以承接下一个新功能的开发工作了。

　　“Release branch”产生新提交的最好时机是“develop”分支已经基本到达预期的状态，至少希望新功能已经完全从“Feature branches”合并到“develop”分支了。

　　创建“Release branches”，方法是：

git checkout -b release-1.2 develop

./bump-version.sh 1.2 （这个脚本用于将代码所有涉及版本信息的地方都统一修改到1.2，另外，需要用户根据自己的项目去编写适合的bump-version.sh）git commit -a -m "Bumped version number to 1.2"

　　在一段短时间内，在“Release branches”上，我们可以继续修复bug。在此阶段，严禁新功能的并入，新功能应该是被合并到“develop”分支的。

　　经过若干bug修复后，“Release branches”上的代码已经达到可发布状态，此时，需要完成三个动作：第一是将“Release branches”合并到“master”分支，第二是一定要为master上的这个新提交打TAG（记录里程碑），第三是要将“Release branches”合并回“develop”分支。

git checkout master

git merge --no-ff release-1.2

git tag -a 1.2

（使用-u/-s/-a参数会创建tag对象，而非软tag）

git checkout develop

git merge --no-ff release-1.2

git branch -d release-1.2

　　“Hotfix branches”源于“master”，归于“develop”或“master”，通常命名为“hotfix-*”

　　“Hotfix branches”类似于“Release branch”，但产生此分支总是非预期的关键BUG。

　　建议设立“Hotfix branches”的原因是：希望避免“develop分支”新功能的开发必须为BUG修复让路的情况。

　　建立“Hotfix branches”，方法是：

git checkout -b hotfix-1.2.1 master

./bump-version.sh 1.2.1

git commit -a -m "Bumpt version to 1.2.1"

（然后可以开始问题修复工作）

git commit -m "Fixed severe production problem"

（在问题修复后，进行第二次提交）

　　BUG修复后，需要将“Hotfix branches”合并回“master”分支，同时也需要合并回“develop”分支，方法是：

git checkout master

git merge --no-ff hotfix-1.2.1

git tag -a 1.2.1

git checkout develop

git merge --no-ff hotfix-1.2.1

git branch -d hotfix-1.2.1

　　还记得文章开始时的那张大图么，我建议你把这幅大图从这里下载下来，打印出来，贴在你写字台的墙壁上，好处不言而喻。

　　over~

git 开发分支图解相关推荐

Git 开发分支合并到develop分支用法
开发是在本地自己的分支上,提交时将自己本地分支上的内容合并到develop分支上,再提交克隆项目指定分支到本地 git clone -b develop git地址创建自己的本地分支 git ch ...
[Git] 拉开发分支的代码报错
Git拉开发分支的代码报错: fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed ...
git从master转到开发分支
本文翻译自:git pull from master into the development branch I have a branch called dmgr2 (development) an ...
dev分支和master是什么_天天用Git，分支开发你怎么弄的？
来源| juejin.im/post/6844903635533594632 Git 是目前最流行的源代码管理工具.为规范开发,保持代码提交记录以及 git 分支结构清晰,方便后续维护,现规范git的 ...
git新建分支并且在切换分支开发
整合分支到master,忽略分支上提交的记录 1.git checkout master //切换到主分支 2.git merge --squash devbranch //一次性合并分支的多次提 ...
开发的必杀技：Git 的分支管理
摘要:作为一名码农,Git的使用就像家常便饭,时时刻刻都要用到,那么Git分支管理也是必须要掌握的. Git 分支管理几乎每一种版本控制系统都以某种形式支持分支.使用分支意味着你可以从开发主线上分离 ...
git 删除分支_深入浅出图解Git，入门到精通（保姆级教程）
原文链接:https://mp.weixin.qq.com/s/_G3l9urASsFjyrYAZBWhDg 分支管理 Git中比较最重要的一点就是分支的概念,有了分支就有了合并和衍合的操作,「合并」 ...
git 合并分支（开发分支dev合并到主分支master）
开发分支dev合并到主分支master上合并分支操作如下: 1.首先切换到master分支上 git checkout master 2.确保master代码是最新的代码 git pull orig ...
Git工具：开发分支拉取主分支最新代码的实现
场景描述:比如我在9yue_wzh分支上开发,如何操作才能拉取到主分支的最新代码呢? 步骤实现: 1.切换到主分支 git checkout master 2.拉去主分支最新代码 git pull o ...

git 开发分支图解

git 开发分支图解相关推荐

最新文章

热门文章