文章目录
*Git VS. Github
- Git是一个版本管理工具，可以在你电脑不联网的情况下，只在本地使用的一个版本管理工具，其作用就是可以让你更好的管理你的程序。
- 比如你原来提交过的内容，以后虽然修改了，但是通过git这个工具，可以把你原来提交的内容重现出来，这样对于你后来才意识到的一些错误的更改，可以进行还原。
- Github是一个面向开源及私有软件项目的托管平台，是一个网站，因为只支持Git 作为唯一的版本库格式进行托管，故名gitHub。
- 每个程序员自己写的程序，可以在github上建立一个网上的仓库，你每次提交的时候可以把代码提交到网上，这样你的每次提交，别人也都可以看到你的代码，同时别人也可以帮你修改你的代码。
- 这种开源的方式非常方便程序员之间的交流和学习。
1）版本控制
1、什么是版本控制？
版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统，它可以帮助团队更好的沟通协作，从而更好的进行交付，常见的版本控制系统分为集中式版本控制系统（如 SVN）和分布式版本控制系统（如 Git）。
- 为了避免团队使用混乱的分支，可以使用主流的分支策略题。
- 常见的分支策略有以下三种：GitFlow、GitHubFlow 以及 GitLabFlow。
2、分支管理有哪些？
2.1 GitFlow
GitFlow 是这三种分支策略中最早出现的。
2.1.1 GitFlow工作流简介
Gitflow工作流定义了一个围绕项目发布的严格分支模型，它会相对复杂一点，但提供了用于一个健壮的用于管理大型项目的框架，非常适合用来管理大型项目的发布和维护。
贯穿整个开发周期，master和develop分支是一直存在的，master分支可以被视为稳定的分支， 而develop分支是相对稳定的分支，特性开发会在feature分支上进行，发布会在release分支上进行，而bug修复则会在hotfix分支上进行，这样也有效避免了不同类型的开发工作在代码层级的耦合和干扰。
git-flow 的分支管理模型：
主分支
- master：master 对应着生产环境的代码。
- develop：develop 为开发分支，当 develop的代码达到稳定点并准备发布时，需将其合并至 master，然后使用版本号标记该次合并。
临时分支
不同于主要分支，临时分支的生命周期有限，当使用完后需将其删除，临时分支可分为：
- feature：功能分支，从 develop检出，必须合并回 develop。当开发某一功能时，从 develop 中检出 feature 分支，feature分支在开发未完成时一直存在，直到开发完后合并到 develop，然后删除该分支。
- release：预发布分支，从 develop检出，必须合并到 develop 和 master。预发布分支通常用于在发布到测试环境的代码，待测试完成后，合并到 develop 和master。
- hotfix：修复 bug 分支，从 master、release 中检出，必须合并回master、release，如果没有 release，就直接合并回 develop。如果在生产环境发现重大 bug，需要立即解决，可以创建
hotfix-x.x.x分支，然后开始解决问题。修复完成合并到 release 并删除 hotfix。
这些分支中的每一个都有特定的用途，并受严格的规则约束，即哪些分支可能是其原始分支，哪些分支必须是其合并目标。
2.1.2 GitFlow 的优缺点
- 优点：每个分支都有明确的定义，严格按照 GitFlow 管理项目代码的话，很难出现代码混乱；
- 缺点：如果特性分支过多的话很容易造成代码冲突，从而提高了合入的成本；由于每次提交都涉及多个分支，所以 GitFlow 也太不适合提交频率较高的项目。
2.1.3 GitFlow工作流优化
- hotfix和release的结果都要合并到master和develop中，为什么？因为它们的修改结果将持续影响这后续的开发和维护，必须合并以保证代码的一致性。
- 当线上项目需要版本回退，或者需要简单记录迭代版本时，我们常在master分支上打上 Tag 标签，例如：
- 功能发布：release_20190101_当月版本数
- BUG修复：hotfix_20190101_修复次数
2.2 GitLabFlow
GitLabFlow 出现的最晚，GitLabFlow 是开源工具 GitLab 推荐的做法。
GitLabFlow 支持 GitFlow 的分支策略，也支持 GitHubFlow 的“Pull Request”（在 GitLabFlow 中被称为“Merge Request”）。
- 相比于 GitHubFlow，GitLabFlow 增加了对预生产环境和生产环境的管理，即 Master 分支对应为开发环境的分支，预生产和生产环境由其他分支（如 Pre-Production、Production）进行管理。
- 在这种情况下，Master 分支是 Pre-Production 分支的上游，Pre-Production 是 Production 分支的上游；
- GitLabFlow 规定代码必须从上游向下游发展，即新功能或修复 Bug 时，特性分支的代码测试无误后，必须先合入 Master 分支，然后才能由 Master 分支向 Pre-Production 环境合入，最后由 Pre-Production 合入到 Production。
GitLabFlow 中的 MergeRequest 是将一个分支合入到另一个分支的请求，通过 MergeRequest 可以对比合入分支和被合入分支的差异，也可以做代码的 Review。
*常见的项目环境
一般项目都是分几个环境的：
- dev或本地环境
- test测试环境
- staging预发布环境
- production线上环境
dev环境主要是什么？
- 开发同学进行自测，进行功能流程串起来。
- 出现bug之后，进行bug修改及验证，提交代码到test环境。
test环境是什么？
- 测试同学重点关注的，进行新功能的测试，提交bug等都是依据test环境进行提交的。
- 进行老功能测试回归，bug回归等。
staging环境是什么？
- staging环境一般是产品同学进行验收，比如看一下开发同学是否按照需求来的，是否有大的问题可能没有考虑到。
- 进行到生产环境的预部署(包括sql兼容语句、UI页面或接口的提前上线等等)。
pro环境是什么？
- pro环境就是正式环境，一般就是我们说的线上环境。
2）版本控制工具
1、版本控制工具应该具备的功能
- 协同修改
- 多人并行不悖的修改服务器端的同一个文件。
- 数据备份
- 不仅保存目录和文件的当前状态，还能够保存每一个提交过的历史状态。
- 版本管理
- 在保存每一个版本的文件信息的时候要做到不保存重复数据，以节约存储空间，提高运行效率。
- 这方面 SVN 采用的是增量式管理的方式，而 Git 采取了文件系统快照的方式。
- 权限控制
- 对团队中参与开发的人员进行权限控制。
- 对团队外开发者贡献的代码进行审核——Git 独有。
- 历史记录
- 查看修改人、修改时间、修改内容、日志信息。
- 将本地文件恢复到某一个历史状态。
- 分支管理
- 允许开发团队在工作过程中多条生产线同时推进任务，进一步提高效率。
2、版本控制工具的种类
2.1 集中式版本控制工具：
CVS、SVN、VSS…
2.2 分布式版本控制工具：
Git、Mercurial、Bazaar、Darcs…
3）Git
请移步《【Git与Github学习（二）】Git的安装和使用》
4）GitHub
【部分内容参考自】
- 【尚硅谷】Git与GitHub基础全套完整版教程：https://www.bilibili.com/video/BV1pW411A7a5?spm_id_from=333.999.0.0
- Jenkins 配合 GitLab 实现分支的自动合并、自动创建 Tag：https://www.cnblogs.com/mycognos/p/10247648.html
- 使用git-flow分支管理模型和Jenkins多分支流水线的应用：https://juejin.cn/post/6963540509142810661
- Git 工作流中常见的三种分支策略：GitFlow、GitHubFlow 和 GitLabFlow：https://juejin.cn/post/6984995032369463326
- 互联网公司的项目会分为哪些环境？：https://zhuanlan.zhihu.com/p/66343803