Golang环境配置
1. Golang 编译环境安装
完成后，安装文件
安装完成后，配置windows的系统环境变量，增加golang\bin目录
2.Windows下安装MinGW，Linux下可以忽略此步骤
完成后，解压文件，生成一个全新文件夹mingw64，将此放到任意位置
进入mingw64\bin文件夹，拷贝mingw32-make.exe文件，并重命名为make.exe
配置windows的系统环境变量，增加mingw64\bin目录
打开
VSCode，进入Extensions，下载其他插件
3. 检验插件是否运作的方法
检查插件goimport是否运作
检查插件golangci-lint是否运作
golangci-lint会自动帮助开发者检查代码有明显语法错误的地方
4. 批量安装Go相关插件
首先，记得开启go module：
1 | go env -w GO111MODULE=on |
其次，修改GOPROXY，将其改为GOPROXY=https://goproxy.cn，命令如下：
1 | go env -w GOPROXY=https://goproxy.cn/ // Windows 或 Linux |
在VSCode下同时按下Ctrl + Shift + P，选择Go:Install/Update Tools，然后点击全选，点OK，下载即可
参考文章
代码合并注意事项
Git分支构成
分支划分如下：
- master：与线上版本保持绝对一致；
- develop：开发分支，由下文提到的release、feature、hotfix分支合并过后的代码；
- feature：实际功能点开发分支，建议每个功能新建一个feature， 具有关联关系的功能公用一个feature分支；
- release：每一次开发完成之后，从develop创建出来的分支，以此分支为基准，进行测试；
- hotfix：该分支主要用于修复线上bug；
命名规范约定如下：
- feature分支命名：feature-name
- release分支命名：release-name
- hotfix分支命名：hotfix-name
比如有一个「优化分布式Session」的需求，可在develop分支的基础上创建新分支 feature-optimize_distributed_session进行开发，开发完成后合并到develop分支。
分支详细介绍和处理流程
master分支
主分支，与线上运行的版本始终保持一致，任何时候都不要直接修改master分支。
一个版本的release分支、hotfix分支开发完成后，会合并代码到master分支，也就是说master分支主要来源于release分支和hotfix分支。
develop分支
开发分支，始终保持最新完成以及bug修复后的代码，新增功能时基于该分支创建feature分支。
一个版本的release分支、hotfix分支开发完成后，也会合并到develop分支，另外，一个版本的feature功能开发完成后，也会合并到develop分支。也就是说develop分支来源于feature、release、hotfix分支。
feature分支
开发新功能或优化现有功能时，会创建feature分支，以develop为基础创建。一般会有多个功能同时开发，但上线时间可能不同，在适当的时候将特定的feature分支合并到develop分支，并创建release分支，进入测试状态。
release分支
当一组feature开发完成，会首先合并到develop分支，开始进入提测阶段时，会创建release分支。
以release分支代码为基准提测，测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。
hotfix分支
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支。
特殊情况处理和注意点
Q:develop分支已存在未上线的feature代码, 此时需要紧急上线一个新功能, 但develop的代码不能上，如何处理？
- 以master为基线创建feature， 在完成之后，代码合并到master分支；
- 为了保证develop是最新代码，需要从master合并到develop分支；
Q:以develop为基线，创建了f1和f2两个feature分支之后, f1,f2开发一半的时候，发现两个分支代码需要有依赖怎么办？
- 最好在开发开始前确定两个功能是否相关,若相关则只创建一个分支,两个功能在一起开发;
- 如果已经创建，则需要合并到一个分支；
一定要保证commit历史记录的整洁，代码合并时，根据情况选择merge或rebase;
使用rebase注意，一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作；
提交说明规范：
- 提交说明最好限制在一行以内，50个字符以下，简明扼要地描述更新内容，空开一行后，再展开详细注解；
- 如果关联jira，写上jira地址；
不同业务代码的管理需求差异
工作中常见的场景
开发周期中，所有的功能在当前周期都能完成，需求评审确认通过且开发任务符合预期：
时间线：D1→D2→D3→D4→S3→M2 。因为经过评估在下一个发布时间前开发人员能够将D1到D4的4个功能完成开发，所以在次期间我们只需要保证这个分支的功能能正常演进即可，尽量不要引进太多的分支。
开发周期中，所有功能在当前周期完成，需求评审确认通过，少部分功能上线时间待定，任务进度符合预期：
这个时候可能存在2条线，大部分人参与当前版本的功能开发（develop分支的演进），少部分人进行未来版本上线的需求开发（F1，F2，F3）。F3→S2 这个合并尽量等到需求拍定上线版本后合并到stage给测试人员测试。
线上BUG的修复：
确认BUG后，如果是测试人员反馈回来的一般会是在JIRA 上提单，我们可以根据jira的issue Id，在master 上 创建一个bugfix-jira-xx，接下来在这个分支上完成补丁的开发（B1→B2），之后合并补丁到stage分支进行测试环境的部署（B2→S4），等待测试人员的验证，验证完成后将补丁合并到master和develop分支（B2→M3，B2→D5），并打一个小版本号的tag。
有个新功能，老板想立马上线，但是发版的时间还没到：
这种情况，把这个功能当成一个超前的feature处理，我们上面说的feature是一个未来版本的功能，可以走未来版本的测试上线流程，这里的feature 是一个超前的功能，我们需要走类似bugfix的流程，进行一个快速的开发上线。
