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

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