这是一个创建于 3381 天前的主题，其中的信息可能已经有所发展或是发生改变。
团队 git 开发中遇到的问题。
Git 分支的设置
一共建立了 2 个远程分支。 dev 和 master.
- master 中的代码是可以直接部署的，目前使用 walle 进行代码的部署。
- dev 中的代码为开发使用
服务器的设置
目前在一台服务器上部署了 2 个环境，
- 一个是开发联调环境。用于给 RD 合作开发使用（使用 git 的 hook 在 push 的时候自动更新代码）
- 一个是测试环境。用于给 QA 同事进行功能的测试。（问题再这里）
遇到的问题
目前开发人员 3 位 合作开发 2 个功能。
- rd1 : 开发功能 1
- rd2 : 开发功能 1
- rd3 : 开发功能 2
目前 rd1 和 rd2 已经开发好功能。需要提交到测试环境进行测试。这里就遇到了一个问题。3 位工程师都在 dev 分支提交了代码，然而 QA 只需要用到 rd1 和 rd2 的代码。 rd3 的代码可能对其他功能产生不可知的影响。
然而问题在于所有的代码都已经在 dev 分支中了，我怎么能做到只发布 RD1 和 RD2 的代码到测试环境中？(难道让他们把涉及到的文件都拎出来，增量上传到测试环境？)
解决方案
正常的情况应该是这样的?
让 RD2 开个新的分支（feature_2）用于开发自己的功能。等 RD1 和 RD2 的功能测试完成之后，到需要测试 RD3 的功能的时候，dev merge feature_2 然后再发布代码至测试环境。
那这个问题怎么办？
领导希望本月只上线 rd1 和 rd2 的功能，但是 rd3 已经把feature_2 merge 至 dev 分支并发布测试了。而且期间 rd1 和 rd2 修复了一些测试的 bug 也一并提交到 dev 分支 并发布到了测试环境。
一开始就用错了么？
在分配功能的时候就应该为 RD1 和 RD2 建立分支feature_1 为 RD3 建立 feature_2
第 1 条附言 2016-07-10 13:00:21 +08:00
整理了下网友们的几个解决方案。都非常不错。看完茅塞顿开。
方案1
- 任何功能都需要建立
feature分支，并且需要建立一个test分支。 - 把需要测试的
feature合并后到test分支。然后从test分支发到测试服务器。 - 上线的时候把经过测试的
feature分支合并到master
方案2
- 从
master分支中建立一个feature_1分支。 - 将RD1和RD2的
commitpick到feature_1分支。 - 然后 RD1和RD2 在
feature_1分支进行开发，开发完后发布到测试环境。 feature_1测试完之后，合并到master进行发布。
方案3
Feature Toggle这个需要一定的工具配合代码发布才能实现。- 补充介绍文章：http://fex.baidu.com/blog/2014/07/feature-flag/
 | 1 Mcatt 2016-07-10 10:55:51 +08:00 从 master 开一个分支比如叫 test 对应贵司的测试环境，任何要到测试环境进行 QA 的代码就合到 test 分支，然后发到 test 。 另外补充开发过程，任何新功能的开发和 bug 的修复都应该开分支去做，然后要开发联调，开发分支就发到 dev ；要测试，就把开发分支发到 test ；要上线就把经过测试的 开发分支合到 master 发布。 ps: 你可以搜索一下 git workflows 这个关键词了解一下。 |
 | 2 beginor 2016-07-10 10:57:47 +08:00 via Android 可以认为是一开始就分错了， 应该建立 feature1 feature2 连个分支， 遇到这种情况， 解决办法从 master 建立一个 feature1 的分支， 将 rd1 和 rd2 的签入 pick 到这个分支， 测试完成之后合并到 master 发布 |
 | 3 jswh 2016-07-10 11:02:47 +08:00 简单来讲，一个环境一个分支。否则不同环境同一个分支出现不同需求的时候就会遇到你这样的情况。 |
 | 4 如一楼所说，加一个 release 分支用于测试并发布。 |
 | 5 yangtukun1412 2016-07-10 11:15:26 +08:00 via Android |
 | 6 xwartz 2016-07-10 11:58:08 +08:00 其实可以使用 feature toggle ，不发布上线的功能关闭就好了，但是也会增加测试的成本，要是写了单元测试应该就没什么问题。 |
 | 7 fhefh 2016-07-10 12:06:21 +08:00 mark~~ |
 | 8 kamikat 2016-07-10 13:10:34 +08:00 @yangtukun1412 又看到这篇老文，前两天遇到楼主的情况就按照这个文章整理了一遍，效果挺好的。方便起见今后还是搞个 gitflow 来管理吧。（才发现这篇文章就是 gitflow 作者写的） 另外，建议每个用户一个分支， feature 分支的方式不方便 rebase ，之后的分支合并树看上去会很乱，每个用户一个分支的好处是用户的开发分支可以随时 rebase 到最新的 develop 分支，每个用户的分支下面再 fork 出 feature 分支，这个做法的坏处就是不能多个用户同时写一个 feature 。两个用户同时写 feature 的时候还可以用 rebase ，三个用户的时候就只能用 merge 了，那样的话树又会变得很难看。 |
 | 9 ayaseangle 2016-07-10 14:31:20 +08:00 特性分支，，， |
 | 10 yegle 2016-07-10 18:31:52 +08:00 feature 应该可以根据配置文件按需在运行时（或者在部署时）打开 |
 | 11 MinonHeart 2016-07-10 19:24:20 +08:00 via iPhone 个人开发某功能的分支 =》功能汇总的特性分支 =》单独的测试分支 =》线上 master 分支 这样向后一级一级合并直到上线。如果是单人开发可以省略第二个分支 |
 | 12 huigeer 2016-07-10 21:23:25 +08:00 via Android 预发布分支 |
 | 13 sexoutsex2011 2016-07-10 21:25:21 +08:00 Git Flow |
 | 14 cxbig 2016-07-11 06:53:04 +08:00 建议先参考一下标准的 git flow 流程，再根据实际情况安排 branch 和 workflow |
 | 15 yseternal 2016-07-11 09:21:09 +08:00 LZ 遇见的问题是多个 feature 同时测试吧， 首先每个 feature 基于 dev 分支拉出对应的 feature 分支，如 feature/a, feature/b, feature/c, 接着各分支进行开发，互不干扰， CI 做自动化发布的时候，每个 feature 分支应该在测试 服务器上有一个目录，然后利用 nginx 进行配置， feature-a.test.com 测试 feature/a 的代码， feature/b 对应 url feature-b.test.com ，分别进行测试。 测试完成后，按照 feature 完成的顺序依次 merge 到 dev 分支，然后在 dev 分支构建，再次 进行 merge 后的一轮测试。 个人不太建议将多个开发中的 feature merge 到一个临时的 branch 进行构建，用一个域名测试， 这样会相互干扰，而且估计冲突很多，没法自动化。 另外 feature 每做完，没有测试完全 ready 是坚决不能 merge 到 dev 分支的。 |
Select Language