问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
以前大多个是一个的使用 Git, 到 Github 上提交的场景, 对多人开发合并项目经验不多,
现在遇到的是在 Github 上存在主分支, 本地需要修改多个功能和 bug 等等,
我是按以前实习回来的同学提示, 在多个分支开发不同的功能, 然后合并提交..
合并和提交的顺序不是确定的, 因此不能简单直接用 merge 每次一个个叠加.
有时我用 rebase, 但有发现 commit 顺序不是时间顺序, 到线上被 merge 以后也不是非常清晰
于是我想问一下面对这样的场景, 用怎样的方式管理会更合适?有在 Google, 但一些细节不清晰.. 比如 commit 显示顺序.. 还有再次被 merge 后的细节..
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
git支持很多种工作流程，我们采用的一般是这样，远程创建一个主分支，本地每人创建功能分支，日常工作流程如下：去自己的工作分支
$ git checkout work工作
....提交工作分支的修改
$ git commit -a回到主分支
$ git checkout master获取远程最新的修改，此时不会产生冲突
$ git pull回到工作分支
$ git checkout work用rebase合并主干的修改，如果有冲突在此时解决
$ git rebase master回到主分支
$ git checkout master合并工作分支的修改，此时不会产生冲突。
$ git merge work提交到远程主干
$ git push这样做的好处是，远程主干上的历史永远是线性的。每个人在本地分支解决冲突，不会在主干上产生冲突。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
上面那位仁兄的回答很好，我这里再补充一个资料，给楼主作为参考。这个是阮兄写的，[git分支管理策略]()。
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
可以在一条分支上一起开发，你有变更的时候，在提交前，使用
这样将本地的修改全部缓存在一个堆栈中了，然后把别人的修改同步过来
git pull --rebase
下一步是将自己的变更恢复到最新的节点上
git stash pop
然后再使用git commit提交，这样就会让一个分支的版本按顺序继续发展，而不是像织毛衣一样，你可以看一下我们使用这种方法前后的对比图
同步到新浪微博
分享到微博？
你好！看起来你挺喜欢这个内容，但是你还没有注册帐号。 当你创建了帐号，我们能准确地追踪你关注的问题，在有新答案或内容的时候收到网页和邮件通知。还能直接向作者咨询更多细节。如果上面的内容有帮助，记得点赞 (????)? 表示感谢。
明天提醒我
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
扫扫下载 App
SegmentFault
一起探索更多未知主干发布与分支发布的区别
我的图书馆
主干发布与分支发布的区别
&&&一：主干发布&&&先说主干发布模式:&以SVN库为例,大致将库分为trunk,&branch,tag三种,主线发布就是公司要发布某个产品的V1版本,之前大家都做会在SVN的trunk上做开发,等trunk稳定了.开出一个分支B1,在B1分支上做V1版本的其它功能添加,bug修改等,并使用持续集成来验证B1的稳定性.直到V1版本达到要求,可以对外发布,并且发布成功后,进行从branch到trunk的merge操作,此时trunk上的内容变成了V1版本的内容,而后trunk上的内容不再允许修改.然后,再发布V2,这个时候,比如下一个版本要发布V2版,这时从trunk的V1版发布的那个点,开一个分支B2出来,再进行V2版的开发,并做持续集成验证V2版的稳定性.直到V2版也达到要求,并且对外发布以后,将B2merge到trunk上,此时的trunk上的内容又变成了V2版本的内容.&依次类推,&直到V3,V4,V5等.我们称这种发布模式为主干发布,因为主干上的东西永远都是发布后的产品,&而且不允许修改.如下图:&如果按照这种方式发布的优点：&第一：可以随时保证trunk上的东西的稳定性，使trunk随时可用；&第二：大部分开发人员不会去触碰trunk，用分支的方式解决实际开发过程中的一些变更（需求变更或设计变更等）；&第三：可以从trunk上随时拿到已发布的任意一个版本。&如果按照这种方式发布存在的不足:&第一:&开发的时候,&持续集成一直在验证着Branch上的稳定性和正确性,而对于release完成后merge到trunk上后,&没有对trunk进行集成验证,&难以保证trunk的稳定性；&第二：违背了SVN的规范，把trunk库当成了tag库去使用；&第三：某些开源项目会采用这种开发（发布）模式，但其中对于验证要求非常严格，merge起来很费时，鉴于开源项目的特殊性，暂不做讨论；&第四：一般采用这种模式发布，是有自己的考虑在里面的。那就是trunk上的东西是不能损坏的，必须随时是好的，即使偶尔出现问题也能及时修正，但trunk已经完全失去了它做为主干的意义，也很难保证SVN库的一致性。&二：分支发布&&&再说分支发布模式:&以SVN库为例,大致将库分为trunk,&branch,&tag三种,所有开发人员基于trunk进行开发,比如也是要发布V1版本的产品,到trunk上的内容稳定后,版本达到了要release的要求,这时从trunk上开分支出来,我们可以称这个B1分支上的内容为pre-release版,此时这个B1分支只为fixbug,&除非有必须要加的新功能.这个时候呢,大部分的开发人员就可以在trunk上开发下一次的发布,而只需要少部分开发人员基于B1分支fix&bug.如果有bug需要在B1和trunk里面都fix的话,就会有少量的merge操作,如非必要,就省心了.&B1分支开出来后,一旦release了,可以根据发布计划,选择是否需要保留.如果近期有发B1的update计划,则可以保留;如果近期都不会再有基于B1的开发,可以将V1发布这一时刻点的B1状态通过tag的方式记录下来,然后消亡B1分支.我们称这种模式为分支发布,因为分支才是发布的线,主干可以一直进行开发,而没有必要停止.如下图:如果按照这种方式发布的优点：&第一：trunk做为开发主线，开发人员可以随时将自己符合要求的代码提交到trunk上，如果在没有必要的条件下，不开分支。同时对trunk做持续集成验证，最大程度上保证trunk的稳定性。&第二：对每次成功的持续集成都同时对库和集成环境做tag操作，发挥tag库的强大作用。&第三：最大量的减少了merge操作，降低了误差。一旦要发布产品，只需从一个稳定的版本（公司上层同意的）发一个分支出来，然后再投入少量的开发人员去进一步优化，主要是fixbug。而这时，大部分开发人员就可以投入到下一个版本的开发中,最大力度的使用人力资源。&第四：其它.&如果按照这种方式发布存在的不足:&第一：配置管理需要随时了解pre-release的分支是否需要保留，以为下一次发布update等做准备。&第二：如果有大型的变更，trunk可能会被破坏，但是如果有一套规范，可以把风险降到最低。（或者也可以通过开分支的方式来解决这种问题）&第三：如果想要真正发挥这种发布模式的威力，配置管理，变更管理，持续集成，质量管理，发布管理每一个模块都是不可少的。原文：.cn/s/blog_5eb1a2670100ewcs.html
发表评论：
TA的最新馆藏[转]&3264人阅读
开发策略（11）
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& author：crylearner
日常开发中几个常见过程
ü& 功能开发 (开发人员)
ü& bug修复，包括测试版本的bugfix和生产版本的hotfix (开发人员)
ü& 版本集成，包括发布测试版本和生产版本 (项目经理)
ü& 版本测试 (测试人员)
分支策略的核心任务
ü& 保证bug修复与功能开发并行，不会出现堵塞情形。
ü& 保证可以快速版本集成。
实现方式就是多分支 + 里程碑标记
多分支策略
1.&&&&&&&develop开发分支
开发人员日常开发时使用的分支，它代表着最新的开发状态。大多数的时候，最新节点的版本是未经检验的、不可靠的。
为了使develop的开发状态可控，根据代码提交频度，定期做一次集成+基本用例测试。如果可以引入单元测试，就更好了。
2.&&&&&&&feature特性开发分支
特性开发分支作为对开发分支的补充，保证不会因为特性开发的不完整，导致develop开发分支的不稳定。
对大型功能的开发，或者试验性的开发，可以单独在本地检出feature分支进行开发。只要定期自己将develop分支的内容同步过来即可。
3.&&&&&&&master 主干分支
代表着稳定状态的分支。任何时候，master分支的最新节点应该都是随时可发布的。
当完成一个里程碑时(完成版本发布、完成hotfix)，应该在主干分支上打上tag，同时将变更内容同步到开发分支。
4.&&&&&&&release 版本发布分支
实际一般主要用于发布测试版本，并提供开发人员在此分支上完成测试版本的bug修复。(如果是发布生产版本，一般直接取用某个测试版本即可)
ü& 测试版本应该从开发版本的当前最新节点检出。为了尽可能保证该节点的稳定性，项目经理应该提前通知开发人员做好代码提交。
ü& 修复bug时，可采用敏捷方式。通过每日集成+回归测试（只测试最新标记为修复的bug），完成快速迭代。
ü& bug修复完成后，由项目经理将分支合入主干，并打上tag，同时将主干内容同步到开发分支develop。 bug修复完成后，release分支也不再有存在价值，可以由项目经理删除。
5.&&&&&&&hotfix& 生产版本bug修复分支
修复时，从主干分支上找到对应该生产版本的tag。基于此tag检出hotfix分支，完成修复后合入到主干master，同时打上tag，删除hotfix分支。（同时也别忘了将主干分支往开发分支做一次正向同步）
后记：如果是基于git的版本控制，只有develop分支是必需长期存在的，其他分支事实上都是可以临时性质的。也就是表面上的单分支，也是我以前公司使用的策略（不过也不完全一致，因为完全的多分支管理也确实比较复杂）。
参考文档：主要是基于第一份参考文档。
1. 《一个成功的Git分支策略模型》
2. 《有策略的进行分支》
3. 《敏捷开发模式中的分支管理模式》
4. 《敏捷开发模式中的分支管理模式实战与补遗》
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：391368次
积分：3530
积分：3530
排名：第7609名
原创：77篇
转载：11篇
评论：80条
(7)(5)(3)(2)(1)(4)(14)(1)(3)(12)(1)(8)(1)(11)(1)(2)(1)(2)(1)(4)(1)(1)(2)}