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

merge master 到 feature 也没啥，最后 merge feature 回去的时候只用 squash merge 就好了。像 github 这些先 merge master 到 feature 算是常规操作了。

我一般的操作是：
1. master rebase 到 feature ， 在 feature 中做冲突处理，不变更 master 。
2. feature merge 到 master ，铁不冲突。

之前在某 杭州中厂外包，要合并代码到生产分支前要提交 merge request 。冲突了要求用第二种方式。。。

@sir283 叫你 leader 下午去趟财务室

首先前提是 master 是当做《发布前预发布分支》用还是《发布后归档分支》用？

不能直接合给 feature 的唯一风险就是其他已经合入 master 的 feature 不上了……一合的话不就污染了么。

方案 1 是把 master 同时当做这两者在用了。

方案 2 看上去是打算把 master1 当做发布前预发布分支用，意味着可能有不同人的不同 feature 分支都在此汇聚解决冲突。同时也可以不影响 master 归档分支。如果万一发布前有哪个需求不上了，也可以重新拉个 master2 来合。待发布完成尘埃落定后合入 master 。

feature 直接 merge 到 master 啊。开个 master_1 干啥。
有 PR 不就行了。PR code review ，jenkins automation 过了就能合并。

master_1 多次一举。

感觉是怕把 master 搞坏，才要开个 master_1, 流程完善，不可能有问题的。

首先要看怎么理解你说的“合入”。

如果是 merge 操作，无论哪种都是极其危险的操作，因为会破坏原有分支的 commit 顺序，想要把合入了 feat 功能分支合入 master ，只能是 push -f 了，这是不现实的，正常这些分支都会有保护，不允许这么做。

如果是 rebase 分支，那其实没啥区别了，唯一的区别应该就是楼上说的，保持 feat 分支的独立性，这感觉在实际开发中不存在，不太可能你负责的功能跟别的模块没有任何数据交互，你迟早要 rebase 到最新的 master 分支。

1. 先在 master 分支上 pull remote
2. 然后在 feature 分支上 rebase master ，解决冲突
3. 把 feature 分支 merge 到 master
4. 在 master 分支上 push remote

如果是多人合作，那么最好有一个 maintainer 来干这个事。然后：
developer：
1. 更新 master
2. 然后在 feature 分支上 rebase master ，解决冲突
3. feature 分支推送到 remote

maintainer：
1. 更新 master
2. 拉取 remote 的 feature 分支到本地
3. 合并 feature 到 master
4. 推送 master 分支到 remote

正常上线都会有个 release 分支, master 切出来的, 把 release 分支合到 feature 解决冲突再合回去就行.
如果没有 release, 犯不着 master 再搞个 master_1.

最舒服的做法：
在 feature 分支执行 git rebase master 有冲突就解决冲突，解决冲突之后 git push --force-with-lease origin feature ，推上去之后再新建一个 Pull Request ，将 feature 合并到 master ，这时候就可以合并了。

方案二是基操吧？
反正我基本是方式二。
如果从 master 合入你的分支，不就相当于以你作为主分支吗？

@sfz97308 有个问题，如果是 feature rebase master 相当于 master 的提交在 feature 重放，如果 featue 去合并 master 会出现文件内容一样但是提示冲突的问题，是我操作不对吗

rebase +1

当我刚入行时，也经常使用 merge 合并分支，并且排斥其他的分支合并方式，不过敲了十年代码以后，踩得坑多了以后，我觉得现在我的提交流程是最正确且最合理的。

给你说一下我一般的操作流程：

基于 feature 分值创建 feature_0305 分支，

在 feature_0305 分支上执行 git rebase master ，

执行完 rebase 后，feature_0305 分支最前面的几次提交应该都是你自己的提交，再执行 git rebase -i commit_hash ，把你自己的提交压缩成一个 commit_new ，

这样分支 feature_0305 的 HEAD 就只指向了一个 commit_new ，这个时候再切回 master 分支，使用 git cherry-picker 把 commit_new 这一个提交遴选到 master 分支。

这样的好处是 master 分支的每一个 commit 都是一个 owner 对应的功能代码，不会出现使用 merge 时那种情况，一个人进个需求代码，master 分支多了几十个 commit ，且时间线还是乱的。

总结：推荐熟练使用 rebase ，不要使用 merge 。

我觉得都没问题

leader 让搞一个单独的 master_1 可能是把 feature 分支当成 backup 分支来看待了

这种情况 leader 没有方向性的错误，就当成他的个人喜好吧

这种冲突是别的分支先合进 master 了吧, 每天早上 rebase 可以减少这种问题出现的概率

好奇大家为什么都用 rebase ， 如果使用 git flow 这种开发方式，大家都往 develop 分支合，rebase 会引入无穷无尽的问题

代码合并分两种形式：非/同源。

同源合并，建议使用 git rebase ，可以保证代码历史呈线性增长，容易溯本逐源。举个例子，feat 向 dev 合并时，使用 git rebase ，如果出现冲突，在本地解决后再重新推送合并请求。

非同源合并，即跨分支合并。建议使用 git merge ，减少代码冲突，使用 git rebase 会出现无穷无尽的 confict 。举个例子，dev 向 master 合并时，使用 git merge ，如果出现冲突，优先使用 dev ，强制覆盖 master ，顺带加上 squash ，清理开发 commit 。

以上希望对你有帮助

没有测试分支吗，如果习惯了第一种，直接把 test 合入 feature 那就 gg 了

@Bingchunmoli "相当于 master 的提交在 feature 重放"这个理解是有问题的，可以理解为相当于你重新从最新的 master 拉出了新的分支，并把你在 feature 分支里的 commits 放进去，应该是你的操作有问题。
可以看下： https://git-scm.com/book/en/v2/Git-Branching-Rebasing

@gzyguy 我们会用 feature 在测试阶段、uat 阶段分别 merge 到 test 和 uat 。
假如已经合入过一次 test 分支了，然后 master 分支有更新，在 feature rebase master 。这时候再去 merge 到 test 会出现改动内容一样但提示冲突吧？ 应该是因为 rebase master 之后 commit id 都变了，跟之前 merge 到 test 的 commit id 不同了。

还是说合 test 也不用 merge 方式了？