Git 的正确使用姿势与最佳实践
Git是我们作为程序员最熟悉不过的工具了，虽然，我们使用最多的可能是git clone把别人的优秀开源项目克隆到本地，但是，当我们需要进行团队协作开发以及源码版本控制时，Git仍然是我们的不二之选。
关于Git
Git是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL许可协议发布。最初目的是为了更好地管理Linux内核开发而设计。应注意的是，这与GNU Interactive Tools（一个类似Norton Commander界面的文件管理器）不同。
Git最初的开发动力来自于BitKeeper和Monotone。git最初只是作为一个可以被其他前端（比如Cogito或Stgit）包装的后端而开发的，但后来git内核已经成熟到可以独立地用作版本控制。很多被广泛使用的软件项目都使用 git 进行版本控制，其中包括 Linux 内核、X.Org服务器和OLPC内核等项目的开发流程。
Git基本使用
相信大家都已经安装好了Git，Git的基本配置网上也有很多教程，这里就不展开了。这里通过Gitee来带大家复习一下Git的一些基本使用。
建立仓库
我们先在本地创建一个tiktok文件夹，在文件夹下输入cmd命令git init，将输出
Initialized empty Git repository in /path/tiktok/.git/
接着，我们在gitee网站上创建一个新仓库，输入仓库名，设置仓库是开源还是私有等，点击确认，Gitee会跳转到仓库初始化帮助界面。我们可以复制这个界面给出的地址，如https://gitee.com/你的用户名/tiktok.git
推送项目
接着我们在本地仓库进行add、commit等操作，再输入以下语句将远程仓库添加到remote：
git remote add origin https://gitee.com/你的用户名/tiktok.git
再进行push操作将本地提交推送到远程：
git push -u origin "master"
这时，就可以在Gitee上看到刚刚本地推送的提交信息了。此外，Gitee仓库默认是私有仓库，如果要将队友添加到仓库中，需要在仓库设置中的成员管理页面，通过链接或二维码等邀请成员进入仓库。
Git工作流程
参考菜鸟教程中的Git教程，常规的工作流程如下：
- 克隆 Git 资源作为工作目录。
- 在克隆的资源上添加或修改文件。
- 如果其他人修改了，你可以更新资源。
- 在提交前查看修改。
- 提交修改。
- 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。
但是我们希望能在这个流程中添加代码审查和自动化测试等功能，从而实现CI/CD，提高团队协作效率，因此，我们团队在进行Git协作时使用如下的工作流程（基于Github）：
创建主仓库
首先，我们会让团队中一个人创建一个Github仓库，并构建好大致的项目结构，添加README文件等。项目如果设置为私有，需要将其他成员邀请进来。我们仓库直接使用的是开源模式，因此直接将项目地址发给大家即可。
Step 1 Fork主仓库
为了保证我们能进行高质量、严格的团队协作，我们并不是让大家采用git clone的方式克隆项目到本地，而是使用Github的Fork功能，每个人都将主仓库Fork一份到自己的Github账户中，每个人在fork仓库中进行修改，修改完成后再发起pr，最后再进行merge操作。值得一提的是，Github中为fork仓库提供了同步功能。当fork仓库落后于主仓库时，可以通过一键同步功能，来获取最新提交，这个功能非常简便，建议大家使用。
Step 2 在新分支中进行开发
通过团队协作实践，我们总结出了在fork仓库中进行开发的最佳实践。即
- 在本地克隆了fork仓库之后，通过该命令创建新分支：
git checkout -b name - 在新分支中编写代码，进行开发，并进行add、commit和push等操作
- 发起Pull Request，发起将fork仓库里的新分支merge到主仓库main分支的请求
- 主仓库中的collaborators处理Pull Request
- 代码merge成功后，即可将分支删除
这里对上述fork仓库中的开发过程进行一些解释。
- 创建新分支开发的原因是：fork仓库main分支仅用来同步拉取主仓库main分支的最新提交。同步操作之后会在main分支生成一条merge记录，如果直接用main分支进行开发，发起的Pull Request将包含这条merge记录，导致主仓库有冗余历史，而用新分支开发则不会有这个问题
- 建议每次进行一个任务都创建一个新分支，任务完成即将分支删除，保证提交记录简洁
- 在进行一次任务前，建议都在Github上进行一次同步操作，并且在任务完成后检查同步操作与需要提交的PR是否发生了冲突，若发生冲突，先解决，再发起PR。
Step 3 自动化测试
为了使项目提交更加规范，我们尽量保证每一次PR提交都包含测试文件。并且，我们通过Github的Github Action功能，当发起Pull Request时，会自动检测其中的测试文件，进行构建、运行并得到测试结果，自动化测试必须通过才能进行Merge操作。具体如何进行自动化测试的部署可以参考Git - Git 钩子 (git-scm.com)
Step 4 代码审查
当自动化测试通过后，我们将进行手动代码审查。这一步主要是审查代码中变量名的语法、命名规范、代码风格、缩进以及一些自动审查工具无法检测出的逻辑问题等。我们团队中一般由2-3人负责这一部分，若这几人都认为代码暂时没有问题，即可进行Merge。如果代码中有部分问题，这几人会在Github上发起评论，可以标注在具体的代码上，以便于更改。如果代码问题非常严重，或者出现了Git使用不规范等问题，我们一般会直接打回PR，修改后再重新发起。这样一来，我们可以最大程度地保证代码风格一致性，并且在后期也能降低因为前期的疏忽而大批修改代码的麻烦。
Step 5 合并操作
完成了前面四步之后，这一步就是一次任务的收尾工作了。当自动化测试通过并且代码审查结果为"Approve"的前提下，Collaborators就可以直接点击Merge，将PR中的提交合并到主仓库。
结语
每个团队都有不一样的开发和协作规范，本文的目的仅在于记录我们团队中的协作实践，并且提供一种可行的工作流程思路。我们团队的工作流程或许还有一些缺陷，也许还不能称为“最佳”。如果读者还有自己的见解，欢迎大家一起进行交流，发掘Git的最佳实践。
