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

一位网友说
  • 7

假设个人分支有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这件事)

回复
阅读 2.5k
7 个回答

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

个人规范

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

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

你可以理解为一个规范,比较主流的git-flow如下
image.png
master
生产代码。git flow 带来的重大变化是你实际上从未在 master 上编码。这里的一切都是通过合并或拉取请求完成的。

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

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

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

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

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

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

主要是为了减少冲突

netwjx
  • -2
新手上路,请多包涵

为什么不能直接

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

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

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

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

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

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

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
你知道吗?

宣传栏