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

方法 1 不讲究，但是比较简单，很多人都只会这样。
方法 2 的话，如果在后来 merge 到 master 的时候如果发生了 fast-forward merge 的话，本质上和 rebase 是一样的。而如果这个临时分支和 master 分支是一样的，即 remote master 还没新的提交的时候，我记得没错的话默认会发生 ff 合并。

总结下，最好本地 rebase 之后 force push 到 feature 分支，然后直接合并到 master 。方法 2 可能可以得到一样的效果，算次优吧。

不讲究随便弄就来回 merge 好了，又不是不能用，反正代码不会丢。

不对，讲错了，更正下：即使 ff 合并也 rebase 后合并不一样，冲突解决的部分是发生在 merge commit 里的。
不过结论不变。

我们是两个都用，当没有冲突的时候直接提 pr ，当有冲突的时候从 master 创建一个新的分支然后把 feature 合并到新分支之后 使用新的分支再提 pr

@JYii 是的。二就是这么用的，发布过没问题的版本才会被合入真正的 master 。

都不用，用 rebase

二有个叫法叫做 release 分支，多分支合作开发的时候，通过 release 分支合并不同的 feature 分支代码发布，发布完成之后再合入 master 。

开发分支的 commit 比较少的情况下，可以使用 rebase （没把我别用），这样 git log 是一条直线美观。使用 merge 多了后 gitlog 看着比较乱

@Rickkkkkkk 喜欢打小报告的小哥哥一枚呀

@mywjyw 你也不喜欢看一堆 ai 回答吧

一堆人说是一样的？？
feature 分支被污染了你说是一样的？ master 被回滚你的 feature 分支怎么上线？

@jamel 一针见血

回滚的话肯定用 tag 啊。第一种没什么问题，本地解决冲突再去 merge 到主 master ，不过有精力的话，rebase 肯定是最佳选择。

github 的 squash 挺好用的。

将 main 合入 feaure 分支解决冲突不应该是常规操作了吗？

在我看来，这两种思路本质上是把 master 合并到 feature 还是把 feature 合并到 master 的问题。
无论哪一种，只要你没有用到 no-ff ，都是会产生一个新的合并出来。
如果用到了 no-ff ，那我猜可能你 LD 的做法出来的图会好看些？（人在火车上，没有电脑没办法实践，你可以试试）

@jokechen 写反了，如果用了 ff ，你 LD 的图可能好看些。

学一下 rebase 吧，这才是你问题的最正确解法

我感觉我周围很多人都很依赖 git 的合并算法，其实冲突比较多的时候，最好是拉着同事一起合代码，这样最保险。

我们小公司习惯用 rebase ，然后 merge 。一般自己的提交在提交前都 stash ，更最新之后 stash apply 解决自己的冲突然后 push ，再在主分支 merge 新的 feat

哈哈，我们就是当 svn 用，直接 master 一把梭

我的习惯是将自己的 feature 分支频繁 rebase 到 master 分支，如果出现冲突，在自己的 feature 分支里该回滚就 reset ，该整理 commit 就 squash ，该强制推送就强推，保证合并回 master 分支时没有冲突，并且 git graph 是能清晰向前推进的。