0、 单人开发场景
单人开发可能会出现的场景之一
如果多人协同开发我们则需要使用更加专业的工具Git（分布式版本控制）
1、多人协同工作使用git会出现什么问题?
代码冲突：
问题： 当多个开发者同时修改同一文件或同一行代码时，可能会发生冲突，导致合并失败。
解决： 定期拉取最新的代码，确保本地工作副本是最新的。解决冲突时，可以使用合并工具手动解决，或者与其他开发者协商如何合并。
分支管理问题：
问题： 不正确的分支管理可能导致代码混乱，不同功能或修复可能在不同的分支上进行，但合并不当可能导致问题。
解决： 采用清晰的分支策略，例如使用 Gitflow、GitHub Flow 或 GitLab Flow。确保团队成员了解并遵循这些策略。
不一致的编码规范：
问题： 不同的开发者可能有不同的编码风格和规范，导致代码难以阅读和维护。
解决： 使用代码审查工具来强制一致的编码规范。在团队中共享和讨论编码规范，并确保团队成员了解和遵循。
优秀的git commit（上） 和 一般的git commit（下）
2、目前所遇见的问题：
现状：分支管理没有特别约束，代码提交没有强约束，review难度大，回溯问题难。
期望：参考gitlabflow或者gitflow的分支管理，在开发过程中依靠约束提升质量。
3、什么是git工作流？
一套定义了在使用 Git 进行版本控制时如何组织和管理代码的规范或指南。
而当项目处于一个多人协作的状态下，工作流程显得非常之重要。假设当两个甚至多个开发者同时再开发各自新功能时，如果在同一分支上进行协作时，这必然会产生大量的冲突。
而工作流的做法，就是每个开发者可以各自切出一个独立分支，当各自功能实现并且测试成功后，再自行合并到master分支中，甚至无需等待其他功能实现再一起发布。
目的：就是对git分支的进行规范和管理
4、常见的git工作流有哪些？
GItflow、Githubflow、GItlabflow（git工作流不是软件，而是规范）
Gitflow:
Gitflow 使用了一种复杂的分支模型，其中包括 master、develop、feature、release 和 hotfix 分支。
Master分支：
该分支主要用来存放稳定、随时可以上线的版本。
这个分支的来源只能从别的分支合并过来，开发者不会直接commit到这个分支上。
通常我们也会在这个分支上的提交打上版本号标签。
Develop分支：
这个分支主要是所有开发的基础分支。
当要添加功能时，所有功能都是从这个分支切出去的，而功能分支实现后，也都会合并回来这个分支中。
master和develop分支是我们最常见的分支，它们被称作长期分支，一直存活在整个工作流程中，而其它的分支大部分会因任务结束而被删除。
Feature 分支： 功能开发在独立的 feature 分支上进行，完成后合并回 develop 分支。
Release 分支：
发布前的准备工作在 release 分支上进行，包括版本号的增加和文档的更新。
当develop分支完成需求后，就可以从develop分支中开一个release分支，进行上线前最后的测试。
测试完成后，释放release分支将会同时合并到master以及develop分支中。
Hotfix 分支： 针对生产环境的紧急修复在 hotfix 分支上进行。
常见的gitflow开发流程如下图所示：
GitHub Flow:
GitHub Flow 是一种更简化的工作流，只包含 master 分支和短暂的 feature 分支。
Master分支：只有这一个长期存在的分支
Feature 分支： 功能开发在独立的 feature 分支上进行，完成后通过 Pull Request （PR）合并到 master 分支。
PR其实就是code review和discuss
常见的github flow开发流程如下图所示：
GitLab Flow:
GitLab Flow 介于 Gitflow 和 GitHub Flow 之间，它只包含 master 和短暂的 feature 分支，但还包括 production 分支用于持续交付。
吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。
Master分支：主线
Feature 分支：
功能开发在独立的 feature 分支上进行，完成后通过 Merge Request 合并到 master 分支。
Production 分支：
master 分支中的代码被视为处于开发阶段，而 production 分支则用于生产环境部署，确保每次合并到 production 分支的代码都是稳定和可部署的。
常见的gitlab flow开发流程如下图所示：
对于”持续发布”的项目，它建议在master分支以外，再建立不同的环境分支。
比如，”开发环境”的分支是master，”预发环境”的分支是pre-production，”生产环境”的分支是production。
5、如何选择一个合适的git工作流
总结：不同的项目和团队需要根据情况采用不同的工作流
| gitflow | githubflow | gitlabflow | |
|---|---|---|---|
| 使用复杂程度 | 复杂 | 简单 | 适中 |
| 适用场景 | 大型项目和复杂发布流程 | 敏捷开发和持续交付 | 对生产环境的持续交付 |
6、其他规范
commit规范：都需要写Commit message（提交说明）
master分支必须是protected
分支命名规范：feature-xxx，release-xxx，fixbug-xxx
合并分支：使用merge还是rebase
规范的提issue；例如提出issue，并且建立分支解决issue，然后关闭issue
合理的创建tag
…
参考引用
https://www.zhihu.com/question/379545619/answer/1082534586
https://www.ruanyifeng.com/blog/2015/12/git-workflow.html
https://blog.csdn.net/qq_35246620/article/details/65636022
https://www.cnblogs.com/xiaoqi/p/gitlab-flow.html
https://zhuanlan.zhihu.com/p/342020501
https://juejin.cn/post/6989145079667490847
