Git 应该用 fetch 还是 pull
如果使用 Git 的话，这 2 个命令可能每天都要用几百遍。
相信绝大部分的人都会直接 pull，偶尔 fetch。但是这 2 个到底有什么不同呢？
不打算讨论过多的理论，因为非常枯燥，并且知道了可能也是看得迷迷糊糊。下面就使用场景来说。
应该 Pull 是绝大部分的情况。
针对 Git 使用的是分支管理代码，可以这样理解，在你对你的分支进行 Pull 之前，Git 就会 fetch 一下，当然这个 Fetch 只 Fetch 你的分支，如果你还需要看看其他的分支的话，那么你最好执行下 Fetch 命令。
举个栗子的使用场景，下面的流程可能是大部分人常用的流程。
你现在在处理你的分支称为 ci，项目的主分支是 master。
很多情况你可能是直接 pull 你的分支 ci，在这个时候 fetch 是被执行了。如果你要查看你本地 master 分支的话，那么你切换分支后需要再 pull 一下。
如果你对整个项目 fetch 的话，你就不需要再 pull 了。
因为很多公司的项目规范中不允许对 master 直接提交修改，必须使用 PR 的方式合并到 master，如果你的公司没有这个使用规范的话，那你就记得没事多从 远程 Master 合并下到你本地，没事多 fetch 下吧。
可以理解的就是 fetch 就是把本地仓库和远程仓库同步下，把远程仓库中的修改拉到你本地仓库里面来，但是不会做任何操作。
所以，通常的操作就是当你的分支 ci 里面辛苦工作的时候，只要不切换分支，你就大胆 pull 吧。
通常我们不是一个人工作，这个时候你遇到了一个非常困难的问题，幸好项目组里面有个大神帮你改了。
这个时候他会把他修改的内容 Push 到你的分支 ci 里面。
你需要看看这个大神改了什么，你可以做是直接 pull 就好了，然后在提交日志中看看他改了什么。
因为 pull 会涉及合并（merge）这个时候可能会出现冲突。
如果出现冲突的话，你就需要手动合并冲突后再提交。
这个使用场景是很多人都会遇到的。
通常 master 都是主分支，有些项目会有 dev ，或者不同的供 CI 的分支。
有时候这些分支上面的修改你需要合并到你正在开发的分支上。
这个时候你就可以使用 Pull from 远程的分支到你本地了。在这个命令执行之前也会 fetch。
IJ 提供了 2 个选项，你可以选择 Rebase 也可以选择 Merge。
这个功能能够让你的分支和 Master 上的分支保持一致，能够避免在合并的时候出现很多意想不到的麻烦和冲突。
在 Pull 之前会执行 Fetch，但是这个 Fetch 可能只 Fetch 你当前的分支。
如果你希望你的本地仓库和远程保持一致的话，你就单独执行下 Fetch ，避免在本地合并的时候丢数据。
在对项目从本地进行任何合并之前，记得都先 Fetch 下你的整个项目。
另外早上到公司后打开 IJ 在准备咖啡或者泡茶的时候，没啥事的话就先 pull 下你的分支，然后 fetch 下整个项目，然后开始愉快的一天。
