LMLPHP后院

团队项目开发过程中，如果 GIT 的使用不统一，不规范，或者某些成员对 GIT 的操作不太熟悉，导致分支的合并特别混乱，使用 --graph 参数查看或者后期代码审查都是非常不友好的。

我曾经到过的一家公司，强制所有的合并都使用 pull request，并且强制所有的 pull request 都必须 rebase 成一个 commit。现在想想，觉得他们很傻，真的很傻，如果一个公司对于技术只有偏执，没有一个非常强的人来设定一个合理的规矩，那是很悲哀的。

在项目的开发过程中，我觉得比较好的方式是切换一个新的分支来开发，名字可以随意取自己喜欢的，最好是包含一些本次开发的意义。一般主分支也只是用来更新，使用 git pull 就比较好，因为这样的话，所有的提交你都可以找到。如果使用 git fetch 来更新主分支的话，有些 commit 在别的分支，你就不能使用 git cherry-pick 检出了。当然 git pull 的方式偶尔会将别人的分支下载到本地，对于有洁癖的人或许不喜欢，关于本地的 origin 分支，还是需要经常的清理的。

如果本次开发的功能涉及的代码比较多，并且提交了多次，我觉得可以使用 pull request 来提交，这样的方式的目的是产生一个 pull request 合并提交记录，方便以后审阅代码。要实现 pull request 效果，需要在合并目标的分支上操作，一般是 master 分支，使用参数 --no-ff 来实现，很多团队所有的操作都在本地进行，唯独合并在网页上，比如 github，gitlab 等，我觉得加上 --no-ff 就可以减少很多时间，不用打开网页来弄，和网页上操作唯一不同的就是 gitlab 或 github 会记录这样一个 pull request 记录，方便筛选。如下示例：

(master) $ git merge --no-ff feature-160703

如果您在开发的过程中，将本次开发的分支推到服务器上了，记得在合并后删除远程分支，远程分支太多了总是不好的。如下：

(master) $ git push origin :feature-160703

如果本次开发只有一个 commit，还要强制产生一个 pull request，那不是傻吗？，直接 cherry-pick 就解决问题了。

(master) $ git cherry-pick ......

谨以此文献给每天写代码的农民哥，希望大家早日出头。