昨天某位仁兄把远程的release合并到master ！！！虽然每个人都会犯错，但是我还想抽他，当然我自己能力不够也是一方面原因，记录一下虎扑最最最最正确的提交流程。
首先我们开发一个功能需要从master上面下拉代码
注意是远程的master，本地的master没啥屌用，因为一般为了提交方便和方便记忆，本地分支和远程分支保持同名，如果你用master 的话，总不能推送到远程master上吧，似乎没人有这个权限。
提交代码前是否要合并master ？ 血的例子，别吧。如果你往master上面提交代码没冲突，那就别合并了，对吧，为啥要合并呢 ？只要你的代码正常上线，dont care anything ，因为要是你真的在这个时候合并了远程master，然后远程master 0.01%的可能是个脏master，这时候你的开发分支也就脏了，意味着你合并master 之后改的东西，在领导发现master 脏了之后，都是要被回滚的，回滚的终结点不一定，凭他们的感觉吧，其实感觉就是那个人把release 合并到master 上的点。那问题来了，如果，万一你真的合并了脏master，咋办，其实也好办，你git reset 到合并master之前的那个commit，重新提交给master，看是否能合并，不能合并，再去解决冲突（后面会介绍冲突解决办法），所以感觉在merge 别的分支的时候一定要做好commit message （最好不要改merge 的info，比如当时我修改改成conflict resolve 我都不知道我要回退到哪个版本，其实只要回退到merge 之前的版本就好了）， 有时候真的会帮大忙，方便你的开发分支剔除掉别的合并的内容
开发feature中是否要合并master ？ 还是血的例子，别吧。万一你开发分支合并了错误的master，万一你不知道，接着在错误分支上开发，当开发很多的时候，当master 需要回滚的时候会很艰难，毕竟开发了那么多。这时候只能继续相信master， 不断的合并master，其实没啥屌用，你的开发分支已经领先master了，如果你没回滚，你合并的时候只会在人家前面，你会多提交很多内容，这些内容在你给领导要求pr merge 的时候被看到肯定会打回来，~~~不知道咋解决
我的流程总结。开发的时候下拉master成为一个开发分支，比如chenye/feature/gray_test, 开发完了，提交dev。万一和dev冲突，下来dev到本地，merge gray_test,看冲突是啥，万一是自己的文件，直接解决。解决完了，推送到远程，给dev提交pr，合并之后，自己的gray_test 就能合并到dev了。注意，在解决冲突的时候一定不要修改自己的开发分支，也就是gray_test, 万一在release 或者 master合并的时候修改了自己的开发分支，一定要dev， release ，master 按顺序重新提交一遍！！！！！否则，别人拉代码的时候一定会冲突。
当发现别人的代码冲突的时候咋办，最好的办法就是告诉别人，因为你不知道以哪个为标准。
你觉得是以master为标准，毕竟线上跑着呢，万一人家当初并不想把代码提交到master上，被另一个同学误操作了，也就是你clone的master是错误代码，这时候以master会覆盖调用dev的正确代码。
你说以dev标准，毕竟dev是最新的代码 ？还是不对，可能别人着急，直接提交了master，也就是说master代码比dev新，这样dev就会覆盖掉master上的新代码。
所以遇到这种情况，直接告知吧，任何一种自己修改别人冲突的方法都是不负责任的行为。
顺带提一下最近遇到的win 和 linux 下空格遇到的问题，我们都知道代码是跑在linux下的，所以我们的换行一定要
用这个LF, win下是
我们既然改变不了win，可以通过phpstorm自带的功能，去编辑文件，模拟在linux下的编辑。
（ps:我是怎么发现这个问题的，在用php的heredoc 换行的时候就能发现）
