提 Pull Request 发生冲突时，大家是怎么解决冲突的？

[hakono]

Github 解决 Pull Request 冲突的方式是：先把目标分支合并到源分支，然后再把源分支合并到目标分支解决冲突

这个做法在一些情况下真的挺危险的，所以想了解下大家是怎么做的

比如，举个例子就是我想把 feature/image 合并到 开发环境的分支 develop 上，然后我提了 pull request，冲突了

我使用 Pull Request 界面里的冲突解决功能，解决了冲突并确认合并，Github 会按照下面的过程解决冲突：

1. 先把 develop 分支合并到 feature/image 分支上解决冲突
2. 再把 feature/image 分支合并回 develop 上完成合并

Github 这样做有个特别大隐患就是， 经过这么一搞， develop 分支上的所有变动和功能都会合并到 feature/image 上

如果有人没注意到这件事想发布 feture/image 到生产环境，把 feature/image 合并到了准 release 环境的分支上，那么准 release 环境就会不光包含 feature/image 的代码，还包含了整个开发环境的所有变动。这在开发环境还有一些测试中的功能的时候很致命

这真的是很有可能发生的问题，我今天就是在 review 一个 release 的过程中发现了这个问题，把这问题拦下来了，没造成大问题

但如果万一有人疏忽可能问题会很大，如果以使用 Pull Request 为前提的话，该怎么解决这个问题的？在 feature/image 上新建个 feature/image-develop-release 分支，然后用这个分支合并到 develop 上？

[ayase252]

我觉得问题在于开发分支不应该上生产环境

[hakono]

@ayase252
我想按照标准的 git flow 那样的流程，开发分支 合并到 develop 分支 然后 develop 分支合并到 release 分支发布的流程

但 git flow 有局限，只适用发布的功能确定且只有一个的情况下， 当同时开发的功能不止一个，并且各自 release 的时机不确定的时候，没法使用 git flow，只能各自的开发功能分支各自合并到线上环境

[tms]

"如果有人没注意到这件事想发布 feture/image 到生产环境，把 feature/image 合并到了准 release 环境的分支上"
这是什么操作。不应该先到 develop 再从 develop 统一发版么。直接从 feature 到 release 真的大丈夫

[hakono]

@tms
"不应该先到 develop 再从 develop 统一发版么"

你说的这个问题其实是我上一个问题的延续，这套流程只能适用于功能发布时间确定且发布功能单一的情况

https://www.v2ex.com/t/639750

按照标准的 git flow 流程是无法解决我这帖子里的情况的

[afx]

按照我们目前的做法，还是一个专门用于发布的分支。

[tms]

@hakono 但是理论上来说因为有多个 feature 和 develop 的存在，每个 feature 在合并到 release 之前都要测试和 develop 还有其他 feature 的兼容性，确实是需要先合并到当前 develop 分支的全部代码的
如果只基于当前 release 代码进行 feature 开发，不想合并其他 develop 代码，要不然考虑一下 hotfix ？

[ayase252]

@hakono git flow 适用于分版本定期发布的项目。像你这种需要持续集成的可以看看 github flow 。但是无论什么 flow，一定要有发布的分支一定要确定，不然在多人协作的情况下都不知道该把新代码合到哪里。一定不能允许非发布分支上线。

[tms]

@hakono 其实不必太拘泥于 git flow 的话，只要不同 feature 是基于同个 develop 或者 master 创建的，发版前只需合并需要的 feature 分支到一个新分支，然后做集成测试。最后 release 即可。在 git flow 里，单 develop 只是起了个汇总作用。

[hakono]

@afx 有点没理解，feature 有多个，但 develop 分支是只有一个的。这个 develop 分支是和线上的开发环境关联的。现在做的事情的确就是 hotfix， 从 release 或 master 分支上新建 多个 feature 分支，在分支上开发完成后合并入 develop 测试，没问题的话 feature 并入 release 发布

然后问题来了， `在分支上开发完成后合并入 develop 测试` 这里是要提出 Pull Request 的，冲突了并在 Github 上解决冲突的话，develop 分支的代码会全部并入 feature 分支，如果没注意到这件事， `没问题的话 feature 并入 release 发布
` 很有可能把整个 develop 环境的代码都给反应到 release 上

[hakono]

@ayase252 感谢回复，其实我为了简化描述才说的 feature 直接并入 生产环境。实际上在那之前还有个 staging 分支用在做发布前内容确定的，但我觉得这也并不是重点，因为 Pull Request 会意外在 Feature 分支中引入目标分支的所有变更这点是没有得到任何解决的

[Kobayashi]

你用错了。解决冲突的正确方法是把 feature/image rebase 到 develop 。

如果是 PR 的话，强推到远程的 feature/image 就可以了，pull request 网页的信息也会跟进。

[Mithril]

没得办法。
无论你用何种分布式版本控制，都会有这问题。唯一的解决办法就是每个分支上提交一遍修改。
无论你是手动 merge 上去的，还是 pr 上去的，还是倒个 patch 再弄，什么 Git Flow，Hg Flow 本质上都一样。

[ayase252]

实际上解决冲突也是在源分支 merge 目标分支，或者 rebase 目标分支，再推上去。和你说的逻辑是一致的。

[aureole999]

打开自动删除 merge 后的分支。这样就不会意外发布了。需要发布的话打好 tag

[afx]

@hakono 懂了，我们的做法跟你们现在是一样的，只是没遇到过在把目标分支合并入主开发分支之后还会再把这个被污染的 feature 分支单独合并到某个分支的情况。

[agdhole]

git flow 不适合持续集成
试下 github flow

[imdong]

我们是两个分支，一个生产分支(pro)，一个测试分支(test)，没有固定的开发分支。

修改 BUG，添加功能时，从生产分支切出一个新分支：bug_xxx，功能名(del_account/)。

然后在这个分支开发，测试时，合并到测试分支，测试完毕，把 bug_xxx 合并到生产分支，

然后生产分支上再测一遍，上生产环境。

正确操作的情况下，不存在测试分支的代码上到生产环境。

当然，幺蛾子一样没少出...

另外，建议多人开发同一个新功能时，单独开一个功能分支(del_account/作为开发分支)，

然后每个人以这个分支再开自己的开发分支(del_account/select_user)

定期合并 上级分支到开发分支即可，但是绝对禁止从 Test 合并代码。

我曾经的设想是，每个人都强制安装 hook，禁止在 pro test 分支 commit 提交代码。

也禁止合并 Test 分支代码。

[msg7086]

你的分支是基于老的版本开发的，如果主干更新了，那么你的分支就是过期分支。将过期分支合并到主干上产生冲突是很正常的。

我推荐的做法是总是 Rebase 到新的版本，然后重新过测试流程。别忘了，你的分支只在旧版本主干上测试过，即使没有冲突也绝不应该直接合并到新版本的主干上，毕竟主干上的版本在先，你的分支在后，保证程序正常运行变成了你的责任。

提 PR 或者 MR 的时候应该保证分支是干净的和最新的。

[francis59]

如果想把 feature/image 上开发的内容合并到 develop 分支进行测试，可以使用 cherry pick，这样 feature/image 保持不变

[ryncv]

把 develop 分支合并到 feature/image 分支上解决冲突是绝对有问题的，我司因为这个吃过几次亏。
目前的操作方案是：出现冲突都是手动到 develop 上去解决， 测试的时候单独拉一个 release，把所有当前版本的 feature 拉过来再回归测试一遍， 最后合到 master