Git的正确使用方式
对于Git的使用，笔者也仅仅是使用过……，今天就简单聊聊何为Git以及如何正确的使用Git来管理我们的项目代码。
Git is a free and open source distributed version control system
Git 是一个免费开源的分布式版本控制系统
The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model.
Git 真正使其区别于几乎所有其他 SCM 的功能是它的分支模型。
以上是从Git官网中摘取的两句的自我介绍，非常简要的说明了Git的功能主要为版本控制。软件系统更新迭代衍生出了版本控制的概念，而Git则在版本控制中提出了分支模型 branching model的概念。
如上图所示，我们会通过Git克隆一份remote repository的master分支代码（在Github上该词汇涉及种族歧视，如今推荐使用main一词作为主分支的title）到本地local repository，然后checkout到该分支（branch），一顿修改后（先pull/update更新当前分支，因为有可能其他人在你clone后push前更新了代码），再选择修改的文件然后提交（git add/commit/push）
当前企业中主要流行的Git分支可以简单视为master/test/dev分支（branch），因此开发者clone的分支是dev分支，该分支用于开发者们协同工作的分支，test分支用于测试环境使用的代码分支，master分支则是生产使用的主线分支。
代码开发完成，需要申请pull request合并分支请求，将dev合并至test，当测试通过，再申请pull request，将test合并至master。code review这一流程其实就体现在合并分支这一时刻。
以上均为正常开发流程的情况，当然也存在一些特殊情况：
1、生产上发生了一个紧急bug，需要立即修复，这个时候又引入了hotfix分支，直接从master分支clone，然后checkout为hotfix分支，当修复好该紧急bug后提交（add/commit/push），申请pull request即可。此后，master分支发生了变化，而基于master分支的test和dev分支还没有该变化，
需要将master 分支上的更新同步到 test 和 dev 分支中，以确保所有分支都包含了最新的修复！（否则下一次迭代后，这个修复好了的bug又会离奇再现）
方案一：
// 拉取master最新的代码
git checkout master
git pull origin master
// 合并 master 分支的更新至test
git checkout test
git merge master
git push origin test
// 合并 master 分支的更新至dev
git checkout dev
git merge master
git push origin dev
方案二：
直接将hotfix分支的更新，于dev分支再写一遍，然后push，从而避免方案一的繁琐操作。2、你和另一个开发者拉取的dev分支，并同时修改了一个文件（他先提交），你pull的时候发现代码冲突了，最好先与他进行沟通，了解他的修改内容，然后再进行冲突解决。
3、A功能需求和B功能需求的上线时间不同，那么开发A功能和开发B功能的开发者就不能使用同一个dev分支，这时又引入了a-feature和b-feature分支，
从本质上来看他们同属于dev分支的子类。
以上便是我对Git使用方式的理解，无论采取的是何种分支策略，我认为整体的版本控制流程大概率都符合以上描述。
