前言
项目刚开始时后端开发只有我一个人，因为不需要跟别人同步代码，所以开发起来也就没那么多规矩了，直接在本地用Git进行版本管理。现在团队慢慢的人多了起来，所以觉得很有必要搭建一个可视化的Git管理工具，并规范一下使用Git的相关工作流程。
目录
- 搭建可视化的Git管理工具
- 制定统一的Git工作流程
- 总结
搭建可视化的Git管理工具
使用Git作为代码版本管理工具需要一台远程服务器，首先先排除类似Gitee、GitHub等免费的代码托管平台，当然不是说这些平台不好，只是公司不太愿意把代码暴露给第三方。
目前市面上开源的Git服务器软件非常之多，常见的有GitLab、Gogs等。
GitLab基于Ruby on Rails开发，功能非常完善，同时还集成了CI/CD功能，扩展起来十分方便；但是GitLab属于比较重量级的软件，运行起来非常吃机器配置，实际测试下来4G内存才能基本保证程序能够流畅运行，如果使用到了CI/CD功能，内存至少8G起步。
Gogs是基于Go语言开发，对比GitLab更加轻量级一些，功能可以满足日常工作中的大部分需求，最关键的是Gogs不吃配置，随便扔到一台机器就能跑起来。
虽然我个人比较偏向于Gogs，但是考虑到后面集成CI/CD实现自动化部署的便捷性，最终还是选择了GitLab（至于机器配置什么的，老板都不在乎我还瞎操什么心呐）。
至于怎么安装GitLab、以及需要注意的坑，我会在后面一篇集成CI/CD功能实现自动部署的文章里详细介绍一下。
制定统一的Git工作流程
因为项目通常都是多人协作开发，而每个人的Git使用习惯都不一样，为了让大家有效地合作，所以有必要规范一下Git工作流程。
市面上常见的Git工作流程也比较多，比较流行的有Git flow、Github flow、Gitlab flow等。
但是一个标准的工作流程很难适应所有的需求场景，总有这样那样的问题存在，比如：Git flow需要维护master和develop两个分支，更适合多版本共存的、有计划低频发布的项目使用；而Github flow则只维护一个master分支，对于高频发布、以及开发人员较少的项目比较适合。
接下来介绍一下我们使用的一套工作流程，大体上遵循Git flow的工作流程规范，然后针对性的进行了一些变动。
当然这并不是什么完美的方案，只能说我们用的还算凑合。当然适合我们团队的也不一定适合大家，每个团队都应该根据自己团队的开发习惯以及业务需求有针对性的调整Git工作流程。
长期分支
项目中维护两个长期存在的分支：master和develop，master对应线上生产环境，develop对应线下测试环境。
master作为主分支的同时也是受保护分支，任何人都不能直接push代码到此分支。master分支上的代码一定是稳定的、可随时部署的状态。
develop作为线下测试分支，总是合并了所有已经开发完成的最新代码，等待合并到master分支。
实践流程
因为主要流程还是遵循Git flow规范，所以我们会在项目中启用Git flow：
引入git flow命令非常简单，在项目根目录执行git flow init命令，根据提示配置一些分支命名规则即可。
引入git flow命令之后，原有的git命令并不会受到影响，git flow的命令本质上只是把标准的Git命令用脚本组合了起来。你仍然可以使用git命令达到同样的效果。
1、新功能开发
当我们开始开发一个新功能时，首先执行git flow命令：
<code>git flow feature start my-feature/<code>
从结果可以看出git flow feature start命令实际上可分解为2个git命令：
- 基于develop分支创建一个名为“feature/my-feature”的分支（这个 “feature/” 是git flow默认的前缀名 ，可在初始化时自定义配置）。在一个独立的分支上进行新功能开发是Git工作流程中最重要的规则之一。
- checkout这个新的分支，可以发现此时代码已经在“feature/my-feature”这个分支上了，我们可以直接开始干活了。
经过一段时间开发，新功能完成了，我们怎么把代码合并到develop分支呢？在feature/my-feature分支commit代码之后，执行git flow命令：
<code>git flow feature finish my-feature/<code>
同样的，git flow feature finish也可以分解为3个git命令：
- 将feature/my-feature分支上改动的代码合并到develop分支。
- 删除掉本地的feature/my-feature分支。
- 将当前代码切换到develop分支。
2、版本发布
项目的发布环境分为线下测试环境和线上生产环境。
每当有代码被合并到develop分支，总是会触发GitLab的CI/CD功能，自动执行测试用例、编译代码并发布到测试环境。
谨慎起见，线上生产环境的发布总是手动触发。
当新功能的代码被合并到develop分支并被push到远程后，因为master分支无法直接push代码，所以我们需要在GitLab项目主页创建一个merge request（同GitHub的pull request类似）通知项目管理人员审核代码，审核通过后代码将会被自动合并到master分支。
当develop分支上的代码被合并到master之后，我们在GitLab上基于master分支创建一个Tag：
基于master分支创建Tag有什么用？
- 记录每次线上生产环境发布当时的最新代码记录，用于后续线上出问题时的回滚操作。
- 手动创建Tag这一动作会自动触发Gitlab的CI/CD功能，自动执行测试用例、编译代码并发布到线上生产环境。
3、热修复
有时候新版本发布之后会暴露出一些新的问题需要我们临时修复一下，此时我们再使用git flow feature命令好像就不太合适了，不过不用担心，贴心的git flow早就为这种情况准备了hotfix命令。
此时我们可以执行命令：
<code>git flow hotfix start fixbug/<code>
该git flow命令可以分解为2个git命令：
- 基于master分支创建一个“hotfix/fixbug”热修复分支。
- 将当前代码切换到热修复分支，直接开始干活吧。
bug修复完成之后，可以使用git flow hotfix finish fixbug命令来合并代码，不同于完成feature分支时只需要将代码合并到develop，hotfix分支的改动既需要合并到master分支，又需要合并到develop分支。
通常情况下我不会直接使用git flow hotfix finish命令，而是手动合并代码到master分支和develop分支，因为在合并到develop分支时容易造成冲突，因为此时develop分支上的代码早已经不同于master分支了。
总结
对于中小型的团队，个人认为Gogs的功能可以覆盖大部分的日常需求，并且不吃机器配置，推荐使用；GitLab更适合一些大中型的团队，当然公司不差钱的话也可以使用，毕竟功能确实多啊！
Git工作流程没有银弹，上面提到的Git flow、Github flow、Gitlab flow等标准化的工作流程，我觉得应该被看作是一个规范，不一定非要去严格执行。
相反，因为每个团队、每个项目的情况都各不相同，我们应该各自团队的习惯、项目的发布周期等因素来确定合适的工作流程。
制定统一的Git工作流程，重点不在于哪一个Git工作流程最好，重点在于确定一个合适的，团队成员都能接受的可执行方案。
“分享知识，收获快乐”
我是一名程序员，喜欢我的文章欢迎 关注 及 转发，我会经常与大家分享一些工作当中的编程技巧与经验。
