本文为日常工作使用，仅做简单的解析，不做深入探究。温馨提示如果你不熟悉命令行，推荐使用可视化界面操作，git 的可视化软件有很多，例如：fork、sourcetree等等。本文是针对个人本地单机上的Git操作，不是 GitFlow 管理流程，注意区分。Git Merge 和 Rebase其实我要吐槽的一个点就是我在项目中看到大量的 Merge 记录，但其实 Merge 并不是这样使用的，大多数情况应当使用 Rebase 变基。首先，为了方便演示，我们先设定两个分支，master 分支和 renfei 分支，其中 master 分支就是我们的基线分支，所以任何冲突和修改都以 master 分支为主，renfei 分支为我自己个人的开发分支，我在这个分支下工作。如果，master 分支上有人提交了新的功能，我需要依赖或者避免后续冲突，我希望把 master 分支的内容拉取到我自己的 renfei 分支，这个时候应该用 git rebase 操作，将我自己的 renfei 分支进行变基变到当前 master 的节点上。如果，我的功能开发完了，需要贡献给 master 分支，这个时候应该用 git merge 操作，将我个人的 renfei 分支融合到 master 分支，并且产生一个 merge commit 提交。Git Rebase 的理解我用大白话和图来讲一下，可能不严谨，我只表示一下意思。在 git 中每个提交都是一个节点，组成的链条，就像链表一样，我们只需要修改一下链表的指针，就可以快速的编辑这个链条，所以变基操作我理解的是下面这个图：
由于 master 分支继续提交，原本的链表落后了，我们只需要修改链表的指针，指向最新的节点即可把 master 分支的变化拉取进自己的分支。Git Merge 的理解我用大白话和图来讲一下，可能不严谨，我只表示一下意思。我的理解，merge 就是把一个分支的所有修改打包成一个 commit 提交，作为新的提交连接到目标分支，如下图：
有同学可能会问，为什么不用变基那样改指针？我是这样理解的，master 分支作为基线分支，上面的代码是可信的、安全的、权威的，而自己的开发分支是不可信的、不安全的，所以需要把你的任何修改都作为一个 commit 提交，如果一旦有问题，可以快速回滚这个提交，从而把有问题的代码恢复回去。什么时候使用 Git Merge/Rebase我做个总结，如果你是把权威分支的代码拉取到自己的分支或者不信任的分支中，那就使用 Git Rebase 变基；如果你要往权威分支中贡献代码，那你应该使用 Git Merge。关于 MR（Merge Requests）有些团队会要求往权威分支合并时提交 MR（Merge Requests）合并请求，而不是自己 Merge 以后 push，保护分支禁止 push。有些团队则没有这类规定，如果团队较小、大家合作默契，可以不使用 MR，虽然不符合规定，但往往大家都很忙没有时间跟你 review 代码。不过，我认为 MR 有个好功能，那就是甩锅功能，如果你代码变动巨大，你有点慌，你可以打开一个 MR，然后喊上团队的小伙伴或领导来 review 你的 MR 请求，让他们来点 Merge 按钮，嗯~~出了问题大家一起被锅啊。总结我总结一下我的习惯，从来没出事儿：commit 你可以随便 commit，但是，当你想 push 前，你应该先 pull 并且使用 rebase 变基，然后再 push。commit 的规范此规范推荐执行，但不强制。一个 Commit Message 主要由 Header + Body + Footer 组成，最主要的是 Header，另外两个可选。Header 又由 type、scope、subject 构成，其中 scope 是可选，意思是 commit 受影响的范围，type 主要有以下选项：
举个标准的例子：build(deps): update xxx maven version 这个 Header 的含义就是这个提交将影响构建功能中的依赖，升级了 xxx 的 maven 版本。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。