关于git的使用姿势

前言

其实，长久以来，我都在思考该怎么使用版本库来对项目代码进行管理。记得最早我们用过一次cvs。说实话，其实蛮好用的。有个问题就是，它只支持同一个文件由同一个人编辑。当然，或许也可能是我们当时不会用。总之，它很硬核得解决了冲突，但是其实并不是很好用。
后来，我就开始接触并使用svn了。其实，svn也蛮好用的。逻辑简单清晰。但是吧，对于需要多分支并行或者频繁尝试来说，就不是很方便了。当我开了一个新的分支，它居然把所有的文件都给我复制了一份。这就导致版本库增长速度急剧增长。而且，当我无法连到服务器的时候，其实对于svn管理的代码我基本上是什么都不能做的。
于是，很顺理成章的，我就遇到了git。git名声其实很大，但是当时由于陌生和惧怕复杂所以一直在躲避它。直到后来硬着头皮用了它。蛮好用的，合并代码大部分情况是不需要我们手动处理的，比svn智能多了。如果一个功能没写完，可以先提交到本地，等到一定阶段再推送到远程服务器。而且，分支也很轻，可以随便使用分支搞实验。但是，由于我一直没有遇到别人弄好的git项目和团队协作，其实我并不知道git从惯例上更倾向于怎么惯例代码。直到我最近开始研究开源项目。

git管理项目的错误姿势

之前，我是建立了仓库之后，就建立一个dev分支。由于master默认是保护分支，无法回滚。所以，所有人拉去dev代码，开发后推送到dev分支下。乍看下来没啥问题。其实，这个过程中我遇到过一些想不太通的问题。
首先是，gitlab的develper角色对于git仓库的操作权限似乎太弱了。为什么没法创建分支，没法合并分支，还没有办法操作master。其次是，这样操作其实我们还是满混乱的，整体代码进度基本就是失控的状态。而且，我开了特定版本的分支之后，其实就没必要再将代码合并回master分支了。等等吧。我觉得，在使用git上我没上道。

git管理项目的正确姿势

最近忽然不用管人了，另外由于做了次深入的反思，想要参与进某个开源项目。但是，开源项目是怎么管理的呢？这个问题其实我一直都没有细想，只是听说linux有人提交代码，然后有人审核，将代码合并进去。但是，具体是怎么回事，所谓的提交代码，审核代码以及提交人的代码是怎么来的，我都没细想。记得当时我观察开源中国，团队里的代码命名只有我组进来的成员才能拉去代码，那我怎么加入开源组织里的人员管理呢？后来，我发现不是这么回事，而且，事情比这些都要开放。
关键的流程是这样的：

1. fork：是的，不是先pull代码，而是先fork，将代码迁到自己的仓库。
2. pull私有库：fork后代码会进入到自己的仓库，然后，拉去自己库里的代码，进行维护等等。
3. push到私有库：从自己的库拉去代码，自然也是向自己的库推送代码。这里我们视为代码调整完毕的提交。
4. Merge Request到原有库的目的地分支：这样就将代码合并到了大家共同工作的仓库了。但是，这个过程是要经过管理员审核的。确保代码没有问题才会由对方操作合并进去。这里就是上面说的审核代码后合并进去。

到这里，主干流程就完了。事实上，看到这里我们也就能想明白一些问题了。开发人员确实不需要对公共仓库的操作权限，它们只需要能看代码，能fork就可以了。而我们平常说的，在公共库里创建什么release、dev、test或者每个版本打标签或者开分支什么的也就都能够想通了。

总结

后知后觉吧。曾经的我理论太多，落地太少，以至于这种基本的内容要到现在才能够了解。那曾经给予盲目瞎想的理论基础实际上都没有太多实际用处。不过，我发现，我瞎想的事情也不止有我一个人那么想。总之，实践出真知。从现在开始，加强落地的练习也不算晚。