为什么要先把master merge 进 个人分支 再把个人分支merge 进 master？

Question

假设个人分支有commit master也有别人commit过了
然后我把本地master更新成最新的之后

为什么要
git checkout 个人分支
git merge master
git checkout master
git merge 个人分支

为什么不能直接
git checkout master
git merge 个人分支
？？？

我个人理解是这样本地的master就不会乱，是跟远程同步的，先把它合并到个人分支预演一下，看看合并了有没有问题。确保没问题以后再并到本地master 再推远程。
可是把个人分支合并into master，master乱了有什么关系呢，把冲突修好了不就行了吗。
求解答 (这里不讨论可以用rebase替代merge master这件事)

Answer 1

假如你们的工作流确实是第一种情况的话，那么你的想法是对的，操作得当的时候两种方式的结果并无不同，是这个工作流设计有问题。
一般情况下不推荐对本地的 master 作任何修改，使其始终与远程 master 保持一致，如果线上有突发情况要处理，这时候最方便的就是直接从未改动的 master 切一个临时分支去修复问题。
如果本地所有分支都有commit记录的话，那么临时修复就要找一个分支回退到与线上一致的时间点，改完了又要回到之前的进度，十分繁琐。

Answer 2

个人规范

因为冲突问题，如果你提交了一个 PR 给到 B 同学 , 别人帮你 code review 完之后，去合并代码，发现有冲突。。。这时候怎么办？傻眼了 （你期望 B 同学 帮你处理冲突？）

如果你提前 merge master 到自己分支，处理过冲突之后，再提交 PR ，这时候不就 顺畅很多

Answer 3

你可以理解为一个规范，比较主流的git-flow如下

master
生产代码。git flow 带来的重大变化是你实际上从未在 master 上编码。这里的一切都是通过合并或拉取请求完成的。

Hotfix
比如刚发布生产环境，发现了严重bug，直接master拉取分支进行紧急修补

Develop
develop分支则用来整合各个feature分支。开发中的版本的源代码存放在这里。

Feature
每一个特性(feature)都必须在自己的分支里开发，feature分支派生自develop分支。

当feature开发完毕后，要合并回develop分支。feature分支永远不会和master分支打交道。

release
release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。

Answer 4

因为master最好不要动。最稳定的分支。

Answer 5

主要是为了减少冲突

Answer 6

为什么不能直接

1. git checkout master
2. git merge 个人分支
   ？？？

因为你的同事也会和你一样操作, 在2容易发生冲突, 那么你需要一段时间处理冲突

1. 注意处理冲突的代码, 也是代码, 这部分代码会落到master, 相当于这块业务逻辑有一部分代码在个人分支, 一部分在master
2. 你的同事此时也会干上述一样的事情, 在处理冲突, 那么后push的同学有可能再次遭遇冲突, 那么此时log就看起来很难看了

其次是master分支会设置git hook, 自动触发构建和部署操作, 一般还会设置权限和Reviewer人数约束

Answer 7

一般来说，你不能直接推 master 分支，而是要通过提 PR 的形式贡献你的代码。

为什么要合并 master 呢，是因为在你的 PR 通过后，准备合到 master 时，已经有别人的 PR 已经合到了 master，这时你需要先把 master 合到你的分支，然后再合进 master。