如果你严肃对待编程，就必定会使用"版本管理系统"（Version Control System）。
眼下最流行的"版本管理系统"，非Git莫属。
相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。
但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。
Vincent Driessen提出了一个分支管理的策略，我觉得非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用，Git只是用来举例而已。如果你不熟悉Git，跳过举例部分就可以了。
一、主分支Master
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
二、开发分支Develop
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
Git创建Develop分支的命令：
git checkout -b develop master
将Develop分支发布到Master分支的命令：
# 切换到Master分支
git checkout master# 对Develop分支进行合并
git merge --no-ff develop
这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的《Understanding the Git Workflow》。
三、临时性分支
前面讲到版本库的两条主要分支：Master和Develop。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。
但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。临时性分支主要有三种：
* 功能（feature）分支
* 预发布（release）分支
* 修补bug（fixbug）分支
这三种分支都属于临时性需要，使用完以后，应该删除，使得代码库的常设分支始终只有Master和Develop。
四、 功能分支
接下来，一个个来看这三种"临时性分支"。
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
功能分支的名字，可以采用feature-*的形式命名。
创建一个功能分支：
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 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修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补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
（完）
wangcong 说：
git-flow 不错，推荐一下～
2012年7月 5日 19:47 | # | 引用
nodexy 说：
不错的最佳实践指南。
2012年7月 5日 20:33 | # | 引用
hbc 说：
Scott Chacon 说太复杂了！要用 github-flow！ http://scottchacon.com/2011/08/31/github-flow.html
2012年7月 5日 21:50 | # | 引用
bravluna 说：
创建 develop 分支：git checkout -b develop master ，为什么后面还多个 master？
2012年7月 5日 22:09 | # | 引用
zhaoyou 说：
后面是跟一个master说明，创建的develop分支是基于当前的master， 如果当前就在master分支，则可以不写。 如果当前分支HEAD指向的是别的分支，又想基于master分支创建，就必须写master
2012年7月 5日 23:11 | # | 引用
老赵 说：
阮兄，说句题外话。你的版式似乎对阅读器的支持不是很好，例如Safari的Reader，经过实验估计是p元素太多，但没有突出文章主体，话说只要把文章内容放在article标签里就好了。
2012年7月 6日 00:33 | # | 引用
一酷 说：
赵姐夫也关注阮哥啊。
2012年7月 6日 09:51 | # | 引用
oldrev 说：
有点异议， fixbug 那个我看原文指示的是 fixbug-版本号，我们公司内部的做法是 fixbug-<bug 跟踪系统编号>，配合 bug 跟踪系统使用更加完善。
2012年7月 6日 10:47 | # | 引用
alswl 说：
2012年7月 6日 11:26 | # | 引用
HungYuHei 说：
应该最先是这位人兄推荐这样的做法：http://nvie.com/posts/a-successful-git-branching-model/
然后再搞出了一个 git-flow ：https://github.com/nvie/gitflow/
2012年7月 6日 11:26 | # | 引用
阮一峰 说：
加了一个article标签，好像解决了。
但是为什么作者和日期信息，都会被省略呢……
2012年7月 6日 12:32 | # | 引用
hiessu 说：
感觉分享。
这篇文章怎么说呢，感觉像是原创，其实只是高级翻译了一下。
不如说一下Git flow的实践..
2012年7月 6日 13:54 | # | 引用
makokisami 说：
这不就是ClearCase的默认设置嘛 还是CC最好用啊
2012年7月 6日 15:52 | # | 引用
不纯粹文人 说：
我们公司用的是SVN，感觉也很不错。
2012年7月 6日 20:36 | # | 引用
waveacme 说：
阮兄把原文提炼了一下，还另外配了图，但是老实说，原文写的更详尽一些，更容易理解，而且，原文的图画的更好，呵呵。
2012年7月 6日 23:04 | # | 引用
koijeffery 说：
这样我就明白公司为什么会有两条线，开发者流和测试版本流。在两个版本之间做了一个缓冲。
2012年7月 7日 10:42 | # | 引用
zhangyuan 说：
文章中的流程就是 gitflow 的流程，以前的公司里就是这样用的。默认情况下 gitflow 的修补bug分支叫“hotfix”。
2012年7月 7日 21:41 | # | 引用
found a tiny error 说：
挑个小错误，正文 git merge 的选项 `--no-ff` 被写成了 `--no--ff`，多出来一个‘-’
2012年7月 8日 07:29 | # | 引用
阮一峰 说：
谢谢指出，已经更正了。
2012年7月 8日 15:55 | # | 引用
steven 说：
是用<time>标签定义日期吗？
试试这个，阮兄
<article>
<header>
<h1>title</h1>
<p>Date：<time pubdate="pubdate">7/09/2012</time></p>
<p>Posted by: steven</p>
</header>
<footer>
<p>Copyright</p>
</footer>
</article>
2012年7月 9日 11:40 | # | 引用
herbert d 说：
学习develop分支和--no-ff，谢谢阮大师的漂亮文章。
2012年7月 9日 11:45 | # | 引用
steven 说：
第一次留言，太狼狈了。:(
可参考 http://html5doctor.com/the-article-element/
2012年7月 9日 11:49 | # | 引用
zk546113096 说：
git 2年用户，帮顶一下，我主页也有推广过，哈哈
2012年7月 9日 15:08 | # | 引用
david 说：
排版太舒服了， 让我有点不太适应。
非常好的博文， 会长期关注。
2012年7月 9日 21:33 | # | 引用
沈觅仁 说：
公司里使用SVN，创建一个分支的代价太高了。要完整co几G的文件。
还是svn好啊
2012年7月12日 00:17 | # | 引用
yebw 说：
还是svn用用好了，已经完全能够达到自己的需求，就不去穷装升级使用git了
2012年7月12日 11:42 | # | 引用
virusswb 说：
很不错的best practice
2012年7月17日 15:53 | # | 引用
virusswb 说：
有几个基线。
1主分支，所有的生产环境都是从主干部署的。
2开发分支，开发是持续进行的工作，几乎没有阶段性，几乎没有停止性。
3其他分支，满足一些场景的需要，然后会合并到主分支或开发分支。
场景：
1测试需要。
2正式版本之后的bug修补需要。
不太明白的就是feature分支，为什么？新功能，直接在develop分支上进行不就可以了吗？反正最后也是合并到develop分支，为什么非要单搞一个分支呢？可以举个例子吗？
2012年7月17日 16:06 | # | 引用
huzi 说：
写的很好啊，对我们刚入git的人来说，这样的材料就是最合适的了
搞不懂为什么总有人诸多挑剔
无语
2012年8月16日 11:35 | # | 引用
袁源 说：
学习了，终于大概知道 git 是干嘛的了
2012年9月13日 16:00 | # | 引用
Apple 说：
如果这个功能还没出生就胎死腹中了，那样连合到Develop的过程都不必了吧
2012年9月16日 09:57 | # | 引用
LYcSon 说：
master：提供给用户使用的正式版本
develop：日常开发
开发测试完成后，合并develop到master上发布给用户，发布后发现bug（陆陆续续的发现，可能不止一个），是每个bug都要单独建fixbug分支吗？
2012年9月30日 01:48 | # | 引用
D瓜哥 说：
非常好！我正在使用Git管理自己的代码和文章。但是没有很好的使用分支来进行管理，这好这里有了最佳实践！顶一个！哈哈
2012年10月15日 13:20 | # | 引用
SmartBooks 说：
初尝试Git没多久，今晚掉进Git里了。看了LZ博文，豁然开朗！
2012年12月 4日 21:33 | # | 引用
asdfsx 说：
帮助甚大啊～～～--no-ff这个参数很重要
2013年1月12日 13:46 | # | 引用
D瓜哥 说：
阮老师，您好！问个弱智点的问题：创建从feature或者fixbug分支，需要提交到远程服务器上吗？为什么？
2013年2月23日 15:41 | # | 引用
face 说：
预发布分支
“预发布分支是从Develop分支上面分出来的”，预发布结束以后，我看您是先合并到master分支，再合并到develop分支
这里我就不太懂了
预发布分支是从Develop分支上出来的，发布结束，应该先合并回到Develop，再合并到master吧？
2013年3月22日 13:55 | # | 引用
冰上游鱼 说：
最近勉强会用git管理代码了。但是，对于像我这样，整天写的都是小玩意儿的同学，感觉git用处不大。做大项目才会有用吧。
2013年4月 1日 13:49 | # | 引用
Jak Wings 说：
最近有好心人出了一个在线的形象化的教程 http://pcottle.github.io/learnGitBranching/
能够动态展示分支管理的过程，并提供好几套练习，欢迎大家去帮忙完善啊。
2013年5月24日 23:40 | # | 引用
我要长肉 说：
这个写的真心好，很好的指导帮助！谢谢
2013年6月14日 11:19 | # | 引用
xiezefan 说：
我是新手，请问，git 和 svn 是同类工具么？？？
2013年7月 4日 22:54 | # | 引用
FingerLiu 说：
受教了！！！
请教两个问题。
1如何使用git开发，能最大程度的减少冲突。
2如果使用git来开发的话，是不是也需要每天上班来的时候先从pull获取分支上的最新代码再进行开发呢？
2013年9月 2日 13:36 | # | 引用
无限飞翔 说：
写的非常清晰，谢谢
2013年10月 4日 13:08 | # | 引用
YCH 说：
我理解的是，实验性的新功能开发分支，有可能会被砍的。
有几个基线。
1主分支，所有的生产环境都是从主干部署的。
2开发分支，开发是持续进行的工作，几乎没有阶段性，几乎没有停止性。
3其他分支，满足一些场景的需要，然后会合并到主分支或开发分支。
场景：
1测试需要。
2正式版本之后的bug修补需要。
不太明白的就是feature分支，为什么？新功能，直接在develop分支上进行不就可以了吗？反正最后也是合并到develop分支，为什么非要单搞一个分支呢？可以举个例子吗？
相当受用。
谢谢您。
2013年11月22日 16:55 | # | 引用
biaobiaoqi 说：
ryf的文字展现的功底真强。
2013年11月28日 14:31 | # | 引用
mr_nop 说：
这个是给实践派用的。
看了gitbook上的东西，完全搞不懂git存在的意义。
这样讲，就觉得git好用多了。
2013年12月26日 16:19 | # | 引用
Andie.C 说：
简单明了，帮助很大！谢谢！
2014年3月 1日 16:45 | # | 引用
timzaak 说：
简洁明了。。谢谢！
2014年3月 8日 19:52 | # | 引用
Dennis 说：
还是没有搞清楚为什么要有“预发布分支”,直接在"Develop分支"测试不可以吗？
2014年12月 3日 12:03 | # | 引用
masako 说：
版主，我最近一直在为merge分支代码烦恼，请问我现在要把标签的代码合到分支上。咋弄???
2015年1月14日 16:29 | # | 引用
nbsky 说：
@virusswb：
阶段性的截取 develop 上阶段的新功能，用来测试，并不往上面添加新功能。避免夹带大量的bug。
2015年3月11日 16:00 | # | 引用
nbsky 说：
一个例子：预发布分支的功能基本没有bug了，但是devlop可能还有正在开发的新功能还不稳定或者根本不能用，会导致没办法发布。预发布就是用来从develop截取下一个版本要发布的功能，不在夹杂本次不要的功能，专注于修复bug。
2015年3月11日 16:05 | # | 引用
穆乙 说：
有点不理解的地方是，release合并到master这个过程是有风险的。直接就上线了？
2015年3月28日 20:08 | # | 引用
阿苗 说：
为什么bugfix分支要基于master，基于develop再反合到master，不行么？
2015年4月13日 19:45 | # | 引用
GloolsGuan 说：
全文拜读， 非常不错，最近正在研究GIT部署问题。
2015年5月 5日 11:58 | # | 引用
ChuckLu 说：
有时间的话，可以写一篇关于git的分支处理细节的代码。
比如git rebase，git squash
2015年5月 7日 09:27 | # | 引用
小高 说：
2015年5月12日 00:09 | # | 引用
mousycoder 说：
阮老师 有错别字
主分支只用来分布重大版本
阮老师 我有一套分支管理流程图
应该算是你的总结形象版吧
2015年7月 3日 10:16 | # | 引用
老张 说：
写得很好，谢谢。
2015年7月 9日 14:09 | # | 引用
llorch 说：
阮一峰前辈的日志非常清晰、实用，是我模仿的好榜样~。本篇文章提出的分支管理守则很好地解决了我手上的问题，致谢！
2015年7月20日 06:58 | # | 引用
Sean 说：
我有个问题关于远程master权限读写的问题。因为远程master默认谁都可以往上push，这对于一个正式发布版本来说肯定不允许的，哪怕是误操作。于是在gitlab上可以设置保护远程master分支不被普通开发人员push，这样一来本地master岂不是形同虚设，因为本地develop也会是push到远程dev分支，最后由主程序员或项目组长来线上merge dev到master？不知道是不是这样的流程。
而且现在远程master普通开发人员不可写，这样一来本地hotfix临时分支就无法更新到远程master，而develop分支上又有新的功能在开发，这可如何是好？
2015年7月26日 17:09 | # | 引用
Sean 说：
在github上面我看大家都是先fork到自己的仓库，然后提交pull request，管理员再合并请求。而看到的gitlab文章都是直接git clone 到本地，然后开始add,commit,push了，怎么会有这么大的差别呢
2015年7月26日 17:22 | # | 引用
wegramm 说：
找到一篇雷同的文章,似乎更好读一些:)
http://nvie.com/posts/a-successful-git-branching-model/
2015年8月28日 08:25 | # | 引用
beyond_cheng 说：
两个问题：
1，既然功能开发和bugfix都是单独拉分支的，那么什么情况下会在develop分支上直接提交代码呢？
2，很多时候是多个功能分支同时进行开发的。假设功能分支1已经开发完成，准备合入develop进入测试，如果测试发现问题很多，比预期的发布时间要延迟。而功能分支2也已经开发完成，等待着测试上线，这种情况怎么搞？只能等待功能分支1发布完成或者回退功能分支1的代码吗？
2015年10月 6日 11:34 | # | 引用
yao 说：
是的 最后发版如果是把develop合如master发版，就无法满足你说的这种情况 前后上线需求 单独上线需求 我的解决办法是 从master拉稳定分支开发 合并到develop做开发测试 最后上线 从我的自己开发分支直接合进master上线 别人有没有搞定 就不用担心了 等他开发完 再把自己分支合进master上线就是了 develop只用来当做一个集成开发测试分支 QQ 392190627 欢迎加我讨论git 之前我也是有这疑问非常久
2015年11月18日 11:30 | # | 引用
monkey 说：
个人觉得master不应该是用来发布版本的， 项目最初其实只有develop版本，只有在devlop版本到一定程度才会有release（图中的master）版本。
2015年12月 1日 15:42 | # | 引用
calm2100 说：
第一个问题：
feature分支是基于develop分支的，bugfix有的地方叫hotfix分支基于master分支。发布时，基于develop分支创建预发步分支release-x，由release分支合并到master， 也就是说 develop 分支和master分支之间还有个 预发布分支 release分支。
第二个问题：
“假设功能分支1已经开发完成，准备合入develop进入测试，如果测试发现问题很多” 这句话说明单元测试和集成测试没有做好，才会出现快要提交develop-->release测试时候发现 “问题很多”， 建议交给测试之前先写好单元测试。并测试通过再考虑测试。
2016年1月11日 16:37 | # | 引用
lumpen 说：
请问博主，预发布分支的tag和fixbug的tag如何管理？
例：
预发布成功，tag1.2。但是后来修改bug成功，tag应该是1.2.1？1.3？还是不沿用预发布分支的tag版本号。
希望帮忙解答，多谢。
2016年3月30日 10:03 | # | 引用
zyren 说：
master和 develop 怎么感觉作用重复了，每次开发完或者bugfix后都需要同时合并到master和 develop，感觉它们的状态基本都是一致的，是不是可以去掉一个，比如 master？
2016年6月28日 15:01 | # | 引用
Dor 说：
从 dev 分支切出 feature 1 分支和 feature2 分支，feature 1 分支开发完成合入 dev ，从 dev 切出 rc.1 分支进行测试，然后发现feature1上了预发有 bug，呼哧呼哧的改，这时候 feature2也合入 dev 再切 rc.2 测试了，feature2测试通过，这时候 rc.2 分支中包含了 feature 1 的代码，所以必须等 feature1 修完 bug 才能发布。这不是互相拖延了吗？
2016年7月14日 18:10 | # | 引用
Zillion 说：
对于你的这个例子我的理解是软件开发上线周期是固定的，如果feature1, feature2都要赶上接下来的上线时间点上线，那么预发布是应该在feature1，feature2全部合并到dev后进行测试使用的，这个时候本来就是期望能够尽早发现bug并修复，所以并无互相拖延说法。如果其中一个feature开发进度比较慢会影响正常的升级时间，应该评估是否放弃这个上线时间点上线，考虑延后一个上线时间点上线。
P.S. 一般来说feature1,feature2是相互独立的功能，可以考虑在合并到dev之前先自测。
P.S. 软件就像一直前进的地铁，地铁里的每个乘客就像是软件的一个功能，每个站台（上线时间点）乘客有上有下，赶不上这趟就赶下趟，不能因为你一个人耽误了所有人的时间
2016年7月16日 00:28 | # | 引用
Zillion 说：
master 和 develop 并没有重复。master一直保持很稳定，只接受经过充分测试后的代码。develop一直很活跃，所有的新功能先来找它。它们的状态基本上是不一致的，只有从develop 拉出release分支测试然后合并到master和develop分支这个时间点才有可能是状态一致。但是这就要求这段时间内没有develop分支的变化。
2016年7月16日 00:40 | # | 引用
Eric 说：
问个问题，假设我的git库有两个分支master 和test， 在test分支上打了tag 比如v0.1, 然后又做了其他修改，现在我要合并master分支和test分支上的v0.1这个版本的代码，怎么合并？
我试过先在test上checkout到v0.1这个版本，然后再checkout到master上合并，结果还是合并的test分支的head，而不是v0.1这个版本。谢谢！
2016年7月22日 17:12 | # | 引用
Yin 说：
您好，问下修复bug好了之后给测试人员进行测试，是同时建（release）分支跟（fixbug）分支，还是直接用fixbug上面的代码给测试人员测试,测试好了没问题在建release分支
2016年8月12日 11:17 | # | 引用
grey wolf 说：
我猜直接在fixbug上面测了。kiss原则
2016年9月23日 16:06 | # | 引用
sfj 说：
最后一个“修补bug分支”的例子很不现实。实际场景中，不可能出现bug时，master分支的HEAD还指在出现bug的版本上。所以这个例子不好。至少应该是1.0发布，然后1.1发布。现在1.0上发现一个bug。然后示例一下，该如何从1.0的tag上拉取一个fixbug分支，改完之后又该如何合入master。
2016年11月 6日 18:39 | # | 引用
舜 说：
git 怎么跟踪文件名的大小写变化呢？
2017年6月 7日 18:38 | # | 引用
无痕 说：
如大神所言，master和develop分支甚是关键。其余皆可作为临时性分支，包括功能性，Bug，预发。
个人实践：单人开发，三套环境。因此临时性分支包括3个：dev、preview、release
多人协作开发：项目前期，3个人，没人以自己姓名命名分支。同步代码要合并到master
2017年6月14日 10:13 | # | 引用
kcw 说：
看完这篇文章顿时明白git flow了，通俗易懂！学东西就需要这种文章 。
2017年11月 9日 19:32 | # | 引用
王阳 说：
老师，您的网站程序是自己写的，还是用的现成的软件（WordPress这类），感觉网站很舒服，想问一下怎么弄的，谢谢！！！
2017年12月21日 01:48 | # | 引用
clark 说：
很基础的 git 应用，简单易懂。
希望能看到一些高级应用。
比如：如何回到 tag 的地方。
2018年3月23日 16:31 | # | 引用
陶留军 说：
私以为所有的日常开发都应该基于master拉新分支，开发完成后，先合develop，后合master。
2018年3月27日 10:57 | # | 引用
blacker 说：
对于一个具体的版本出现的bug如何做hotfix?比如用户使用的版本是1.1.1，并在这个版本上发现了bug，但是我们的版本已经到了1.1.5，这之间的好几个版本都没有针对这个bug做任何修复，用户又不希望升级到这个1.1.5版本，这个时候，从master分支checkout出hotfix分支就是不合适的
2018年3月30日 02:01 | # | 引用
lsyarn 说：
阮老师，我刚使用git不久，看了您的文章非常受用，有一个疑问想请教您。如果在release0.1发现了一个bug，该如何处理？我的想法是从develope创建一个fixbug-1分支，修改bug后合并到develope分支，然后在develope分支重新创建release0.1.1用于做测试的预发布版本。但是，我所担心的是在发布release0.1后develope又被合并了其它分支例如feature-z，那么我checkout的fixbug-1就包含了feature-z的代码，这部分代码还会被保留到release0.1.1，而feature-z并不是我想要的在release0.1.*中发布的功能。
2018年5月16日 18:01 | # | 引用
lsyarn 说：
我在这里找到了答案 IBM-Git 分支管理最佳实践。
1. 对于测试中发现的问题，直接在 release 分支上提交修改。完成修改之后再次部署和测试。
2. 当 release 分支中的代码通过测试之后，把 release 分支合并到 develop 和 master 分支，并在 master 分支上添加相应的 tag。
2018年5月16日 18:35 | # | 引用
rabbit 说：
非常感谢推荐
2018年12月14日 14:25 | # | 引用
joker 说：
想请问一下，功能feature-A开发完成之后，处理bug在哪个阶段。还未合并到develop之前？之后？ 还是在release分支上遇到bug，从release分支开出来一个分支处理bug，然后合回release分支？
2018年12月25日 17:50 | # | 引用
Biglucky 说：
请问一下，开发者共用一个跳板的Console机，也就是相当于只有一个本地库。
这种情况一般使用什么样的策略比较好呢？
目前我们一个dev、一个master。
手动将dev贴到另外一个目录下，push到master分支。
之前发生过 dev merge 到master后，很多不想要修改的内容也一并修改了，只得退版。
非常感谢！
还请解惑，
2019年1月23日 18:31 | # | 引用
Steven 说：
感谢分享。
另发现疑似错别字，上面也有其他留言提过了。不过貌似还没处理。 可能提的不够清晰明显，小弟再提一下，位置：
```
二、开发分支Develop
主分支只用来[分]布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
```
上面的`[分]布`是否应替换成`(发)布` 呢？
谢谢
2019年9月29日 10:25 | # | 引用
storm 说：
good 很形象，教程很喜欢+
2020年4月18日 09:16 | # | 引用
须尽欢 说：
我也是这么想的，不应该修改完bug直接就并入 master 分支，应该先并入 develop 分支经过测试没问题后再并入 master 分支
2020年7月17日 15:17 | # | 引用
M兄 说：
这样是不行的。假设MASTER分支上的代码是AAA，DEVELOP分支的代码比MASTER多，假设是AAABBB；然后突然发现线上环境出BUG了，应该把AAA改为aaa。问题来了，如果从DEVELOP分支拉热修复分支，把代码改了之后，再反合并到MASTER，就会把BBB也合并到MASTER，而BBB是正在开发的内容，还没有到上线的时候。所以总结一下热修复分支必须从生产分支也就是MASTER中拉出
2020年9月 8日 10:02 | # | 引用
yanyue404 说：
这种情况可以创建自定义的 merge driver，在 dev 被 merge 到 master 的时候可以保留 master 分支修改的内容。
1、注册 merge driver
注册好的 driver 会像一个过滤器一样在 merge 的时候自动执行。
```bash
# 全局注册自定义 merge driver
git config --global merge.ours.driver true
```
2、设置过滤项
```bash
# .gitattributes 文件（位于项目根目录）
project.config.json merge=ours
fetch.js merge=ours
app.js merge=ours
```
注意： 只能 master 合并其他分支时忽略其他分支上的文件, 其他分支合并 master 无法忽略 master 上的文件，所以这样的操作只能是单向有效。
3、正常的 merge 操作
```bash
git co master
git merge --no-ff dev
```
我的详细文章： https://github.com/yanyue404/blog/issues/180
2020年9月 8日 17:04 | # | 引用
Nine 说：
我感觉功能分支是不是也应该从mater拉取，否则从develop拉取的话，会有很多其他开发中的功能BBB最后合并到master中，因为功能开发是持续性的，很难控制一个时间窗口内develop不变动。
2020年9月24日 13:57 | # | 引用
炑烁 说：
五、预发布分支有点疑惑，预发布分支是从Develop分支上面分出来的，为什么还要再合并到develop分支呢，感觉这里是多余的没有任何意义吧？
2021年3月11日 16:01 | # | 引用
浮心 说：
很有必要，因为开发分支的代码可能有bug，或者代码上的调整，可能弄个预发布测试+调整
2021年4月 8日 15:09 | # | 引用
浮心 说：
功能是基于版本的，正常的开发流程， 都是按版本迭代，一个版本里会有多个功能，这时候就需要搞清楚版本了，对应的功能，只能写在对应的版本里
2021年4月 8日 15:11 | # | 引用
3Q秋 说：
@virusswb：
你想想feature 你怎么知道什么时候开发完呢。没法定上线时间的东西放到开发分支里面不合适
2021年9月 2日 15:18 | # | 引用
老衲 说：
从master 创建新的分支develop，develop 分支的内容跟 master 一模一样。
2022年2月 7日 11:13 | # | 引用
Lee 说：
既然预发布版本是从dev分支分出来的，那预发布版本是是不是也包含了一些未开发完成的代码。这里要如何去划定这次要上线的代码版本呢？
2022年5月13日 10:22 | # | 引用
moosd 说：
在这个策略下
发版时候：dev会合并到master
修复bug的时候：master会合并到dev
但是master和dev本身会有一些不可避免的冲突，例如配置文件、CI文件、Dockerfiles。在有这种不可避免的冲突下，如何实现分支的相互合并？
2023年3月28日 12:24 | # | 引用