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

感觉这两种都是在合入 master 时使用 rebase 的情况下有意义，可以保持 master 是一条线

大厂方案：
1. 开发：基于 master 拉 feature
2. 上线：基于 master 拉 release ，合并 feature 到 release ，发布 release 上线
3. 上线后：合并 release 到 master

总结：
1. 开发：feature
2. 上线：release
3. 备份：master

方案 1 就可以了，除了人情世故，上面那些洋洋洒洒一大堆的以为自己很有经验的，求求你们试试 squash merge 吧，所有问题都解决了

方案 2 类似 gitflow 的模式吧，master_1 等同于 develop

你只需要嗯嗯嗯，好好好，然后自己用方法一就行了

@RightHand 刚想说这个，就是当做 svn 用了
git local 的 master 和 remote 的 master 本来就是两个分支，合并到 master 上是合并到 local 的 master 上其实就是 master1 ，然后在 push 的时候其实是一个 fast forward 。

为什么不把 feature 直接全入 master ，然后解决冲突

1 就行，diff 是关键

为什么不是 rebase ？为什么不是 squash merge ？

rebase 吧？在你的 feature branch 基于 master branch 操作 rebase

你的 dev 和 release 呢
如果非得二选一
应该选择 1
另外，1 是周期性的，并不是上线前

我们是会基于 master 分支 checkout 一个带发版日期的版本分支 A 出来， 然后把多个 feature 合并到分支 A ，解决冲突后，发版时再把分支 A 合并到 master 。类似于你说的方法 2 。

直接在 master 解决 测试没问题再提交代码

feature 与 master 有冲突，说明 feature 版本落后了，要同步下 master 最新代码。
rebase 方式：
```sh
git checkout feature
git pull
git pull --rebase origin master # 更新本地分支，并解决冲突
git push -f # 确保 feature 只有自己使用或着没有别人推代码
#创建 mr ，如果已有 mr ，此时不会再显示冲突。如果过段时间又有冲突，重复此步骤
```

另外还有 merge commit 方式，如果没有 mr 等复杂流程：
```sh
git checkout master
git fetch
git pull
git merge origin/feature # 解决冲突，会产生 1 个 merge commit
git push
```

如果有 mr 流程(与 rebase 方式类似，只是会多 1 个 merge commit)
```sh
git checkout feature
git fetch
git pull
git merge oirgin/master # 解决冲突，会产生 1 个 merge commit
git push
#创建 mr ，如果已有 mr ，此时不会再显示冲突。如果过段时间又有冲突，重复此步骤
```

命令简单写的，不是很精简，理解意思即可

当然还有一些简单的方式
```sh
git checkout feature
git pull --rebase origin master # 解决冲突
git push origin feature:master
```

直接 git push -f ，管它什么冲突，是 lead 叫我 push 的，我只管 push ，出了问题找 lead 。

@Rickkkkkkk 谢谢，38 楼的账号已经被彻底 ban 。

月经贴。。。 说等价的是真没理解 parent / diff 方向的问题

在不用 rebase 的情况下，最好的做法都是「不要把 master/dev 等公共分支合到自己的 feat 分支，始终保持 开发分支->公共分支 单向合并」

这个问题在 v2 上已经讨论过好几次了

尽量避免“直接把 master 合入 feature 解决冲突”

在 feature 分支 rebase 呀，然后再 merge 到 master