请教一个开发流程中 GIT 解决冲突的问题

不理解

2 是脱裤子放 p 。但是想来是你 leader 长期以来的习惯了，也不要去纠正他，没必要。

不理解
master 合入 feature-x 解决冲突，此时 feature-x 不就是等于方案二中的 master_1 吗?

随便，毕竟大部分人把 git 当大号 svn 用

正常不是要 rebase 到最新的 master 么。哪种都行，只要没合并出 bug 。
你跟他争论只会让他对你印象变差，他说啥你都 [嗯] 就完了，逢场作戏的事，私下你该干嘛就干嘛，别理他

除非 master_1 是预生产、预发布，不然即便是回滚，分支线路都没看出什么优势来

从技术上来说，应该没什么区别。
从人情世故上来说，劝你按领导说得来，不要硬刚领导。
---来自过来人的忠告。

二是脱裤子放屁 +1
还有一种选择是 feature rebase 到 master 上

如果 feature 短期内被合入 master ，那我更习惯用 rebase ，并且把 feature 中间的 commit 都去掉，减少对 master 的扰乱

风险控制吧，是多此一举，但就是为了降低风险，建议听领导的

rebase 吧

迭代周期短，变更记录少，用 rebase ；否则，方式一。方式二脱裤子放屁

一 back merge 应该避免
二如果 “把 master_1 合入 master” 是 ff 那就是对的

1 、估计你们用的 git 不规范造成的，一般 feature 合并到 master 为什么会冲突呢，有冲突的话在 feature 应该就解决了
2 、为什么不在本地 master 解决呢，feature 合并到 master 发现有冲突难道还要回滚吗，然后在另起分支解决冲突，感觉有点脱裤子放屁

如果只有一个 feature 分支，方式一，就行。如果多个 feature 分支，推荐方式二。

核心问题在，你的 feature 分支从主分支拉出来之后，就再也不同步主分支的变更了，导致 feature 分支与主分支越走越远。
更好的做法是，在开发阶段频繁地把 feature 分支 rebase 最新的主分支，如果出现冲突及时解决。这样在最后将分支合并回主分支时，feature 分支也依然是 base 在最新的主分支上，则不会有冲突。

说不理解的 都没开发过复杂的场景。比如：
feature/A -> master 有冲突，如果直接 把 master 代码 合到 feature/A 中，这个时候 假如说 不想上线 合并了，你得操作回滚。

另外一个 master 不一定是要上线的代码，可能是 上线前的准备回归封板代码，如果这个时候 feature/B 也合并到了 master 出现了严重 bug ，这个时候 feature/A 同步 master 的代码 就会被污染。

新开一个分支 用来同步 最新的稳定版本的代码 以及 处理冲突，feature/A 要同步 也是 同步 已经上线后的稳定版本代码，而不是 直接 同步 最新的 master 代码。

feature 是 基于 某个时间点的 功能开发版本，不一定非要跟 最新 master 保持同步，feature 的目的 是为了完成 当时那个时间点的需求，开发完成了，就新开一个分支 去合并到 master ，这也可以在 feature 上 继续开发，编码 跟 环境部署测试 是两回事。

如果有很多的冲突 不兼容的问题 是需要团队提前沟通的，不可能说 feature/A 在迭代功能，feature/B 在重构，你这合到 master 怎么玩，还怎么发布上线？

用第二种是怕你把 master 搞乱，又不懂恢复，又或者为了省事，搞错不用回滚等操作。算是一种新手保护，或者团队有人搞乱过。

实际上第一种就最好了。可以的话，尽量 git rebase

第二个操作毫无意义啊，分出最新 master ，再合并回到最新 master ，和操作一 等价。

@lasuar 第一种方式叫循环回合，可能会带来 merge base 爆炸的问题，小项目无所谓随便搞，像远古银行的项目因为不规范导致某些仓库的 merge base 多达上百个，merge 一个小的改动都非常耗时。这种仓库使用 gitlab 、gitee 线上合并是会拒绝的，github 没试过