前言
本人公司在版本控制方面由SVN 转向 Git管理，私仓使用GitLab搭建，理论上可以有效的管理各个项目组程序版本的问题。但开发人员由于是从SVN模式切换到Git，在底层思想上并没有很好的理解Git的分布式版本管理的本质，使用过程中出现了很多各种异常情况：不了解为什么会有冲突、无法合并程序、会覆盖掉别人的程序等等。本文目的就是讲解团队是如何正确使用Git进行程序开发。
遵循的5项原则
在正式介绍如何使用方法之前，先说明一些约定俗成的原则，每个开发人员都要严格遵守：
- 我们要保证master分支一直处于可用状态。
- 阶段性增加的新功能都是在dev开发分支中进行。（dev分支可以理解为开发某个版本分支）
- 每个开发人员都需要建立自己的分支，所有新开发的功能都要在各自分支验证后才能合并到dev分支。
- 只有当dev分支经过充分测试后才能合并到master分支，之后发布到生产环境。
- 为减少长期不合并程序导致版本变动过大冲突过多问题，每天下班前阶段性的把程序合并到dev分支（注：前提不要有bug，会导致其他人程序无法使用）。
团队操作Git的正确过程
根据以上原则给大家画了一张图，先有个整体的概念，起步时千万不要局限在某个具体操作上。我们首先要明确一个目标，那就是要把开发好的程序合并的远程的分支上。围绕这个目标我们接下来看Git是如何优雅的实现的：
1.环境初始化
从环境初始化开始，首先在gitlab 上建立好项目，并初始化所需分支，根据master分支创建dev分支，根据dev分支创建开发人者分支（图中dev_hunter分支）。
2.拉取分支到本地
开发程序第一步都是通过clone 拉取远端的程序到本地，之后通过pull来拉取最新代码。这一步需要明确的是拉取下来的程序是一个全量程序，即不仅包括自己的分支，其他所有分支的程序已经全部拉取下来。
3.本地程序开发 commit 与 push
本地要选择开发者自己的分支进行开发，开发完毕后我们要commit提交代码，此时操作的commit是只是保存在了本机中，接下来通过push命令可以将本地提交的程序推送到远端的自己所负责的分支上。
4.合并程序
在自己分支下提交程序不会有什么问题，因为版本都是相对自己版本在更新。但当开发完程序需要将代码提交dev分支时往往出现的问题比较多。因为在合并程序前其他开发人员可能已经提前将程序合并到了dev分支，这直接会导致自己的分支已经不是最新版本，如果修改了相同的文件还会产生很多冲突。为保证自己分支与dev分支保持同步需要做以下操作：
- pull拉取程序。目的：拉取到远端dev分支最新版本程序到本地。
- rebase合并程序，本地开发分支与远端dev分支进行比较后rebase。 注：本人更建议使用rebase而不是merge，因为最终会得到一个清晰的功能合并线路，相关利弊各位可以自行搜索 。
3. 如果提示有冲突，则说明本地程序版本与最新dev分支不匹配，需要人工对冲突进行处理。
- 冲突处理完毕后，push最新程序到自己的远端分支。
- 在gitlab中提交自己的merge request 申请，如无意外则可以合并到dev分支中。
- 一旦提示无法合并则说明，仍有冲突。需重新操作1-4步，第5步会自动触发，可以进行程序合并。
总结
多人如何正确使用git对代码进行版本管理，相信各位应该已经有了一个整体的认识。整体操作步骤如下：
- pull 拉取程序到本地。
- commit && push 本地开发程序并提交到自己远端分支
- pull 拉取远端最新版本程序
- rebase & push 合并代码，如有冲突则需解决冲突，并提交到自己远端分支
- merge request 合并远端分支到dev分支