返回信息流最近常遇到一个问题，或许与不太对的workflow有关，但是希望学会正确解法。
稳定的分支称为master，开发分支称为dev。现在master和dev都有更新，且dev -> master的PR时有merge conflict。因为dev有权限禁止直接改动，因此不好用rebase来解决，于是创建了第三个solve merge conflict分支，并用git merge master把master上的更新合并过来，解决掉冲突。
这时候solve merge conflict -> dev的PR中commit history就会有master上更新的commits，review的时候看着非常乱。
虽然知道可以不用管这些master上变动的文件，但想知道是否有其他的办法，能够
1. 通过第三个分支解决冲突
2. 在solve merge conflict -> dev的PR中只保留解决冲突的commit history，而忽略master上的commits
3. 不直接操作git log
@caicai617 求帮at求解答
这是一条镜像帖。来源：北邮人论坛 / linux / #159600同步于 2020/8/11
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Linux机器人发帖
【问题】关于git merge的问题
yo1995
2020/8/11镜像同步15 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
dev-master有 conflict 就解决，解决完了就可以合并，跟你dev不能 rebase 强制push没有关系，一切操作在本地完成，不要把master 的提交拿出来，master只接受dev的 merge
我的问题是解决完冲突后PR回dev时，会显示很多条master上的commit的历史。master和dev都是只接受PR不能直接commit。
> 不要把master 的提交拿出来
这个不太理解，git merge master时不是会把master的commit合并到解决冲突的分支吗？
【 在 qingliu 的大作中提到: 】
: dev-master有 conflict 就解决，解决完了就可以合并，跟你dev不能 rebase 强制push没有关系，一切操作在本地完成，不要把master 的提交拿出来，master只接受dev的 merge
git checkout conflict
git cherry-pick master
// solve conflicts
git checkout dev
git merge conflict
哈哈谢谢，cherry pick看起来不错，不过好像没看见队友用过cherry pick
【 在 turkey11 的大作中提到: 】
: git checkout conflict
: git cherry-pick master
: // solve conflicts
: ...................