Git
什么是Git？Git是分布式的，Git不需要有中心服务器，我们每台电脑拥有的东西都是一样的，Git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理，是 Linus Torvalds 为了帮助管理 Linux 内而开发的一个开放源码的版本控制软件。
1. Git如何工作？
首先，当你需要开始一个新的项目或者获取最新的代码时，你可以从远程仓库抓取或克隆代码。这将创建一个本地仓库的副本，并包含所有历史提交记录；在本地仓库中，你可以检出特定的分支或提交，这允许你在不同的版本之间切换，以便查看或修改代码；当你对文件进行更改后，需要使用"git add"命令来添加这些更改到暂存区，这会跟踪你的更改，并准备将其提交到本地仓库； 然后，使用"git commit"命令可以将暂存区中的更改永久保存到本地仓库，每次提交都会创建一个新的快照，记录下当前代码的状态；如果其他人已经向远程仓库推送了新的更改，你可以通过拉取操作将这些更改合并到你的本地仓库中，拉取操作通常由fetch和merge两部分组成，首先从远程仓库获取最新更改，然后将它们合并到你的当前分支上； 最后，当你完成了一些工作并且想要分享给其他人时，可以使用"git push"命令将你的本地更改推送到远程仓库。这样其他团队成员就可以看到并使用你的新代码了。在整个过程中，Git会跟踪每个阶段的状态，并提供各种工具帮助你管理代码库。
上述中涉及的主要工作过程指令详情如下：
- clone（克隆）: 从远程仓库中克隆代码到本地仓库
- checkout （检出）:从本地仓库中检出一个仓库分支然后进行修订
- add（添加）: 在提交前先将代码提交到暂存区
- commit（提交）: 提交到本地仓库。本地仓库中保存修改的各个历史版本
- fetch (抓取) ：从远程仓库抓取到本地仓库，不进行任何的合并动作，一般操作比较少
- pull (拉取) ：从远程仓库拉到本地仓库，自动进行合并(merge)，然后放到到工作区，相当于fetch+merge
- push（推送）: 修改完成后，需要和团队成员共享代码时，将代码推送到远程仓库
2. Git指令详解
2.1.基础操作指令
- git status：查看的修改的状态（暂存区、工作区）
- git add 单个文件名|通配符：添加工作区一个或多个文件的修改到暂存区 (工作区 --> 暂存区)
- git add . ：将所有修改加入暂存区
- git commit -m '注释内容'：提交暂存区内容到本地仓库的当前分支(暂存区 --> 本地仓库)
- git log [option]：查看提交日志
其中options包括：
--all 显示所有分支；
--pretty=oneline 将提交信息显示为一行；
--abbrev-commit 使得输出的commitId更简短；
--graph 以图的形式显示；
- git reset --hard commitID：版本切换或版本回退，其中commitID可以使用git-log或git log指令查看
- git reflog：查看已经删除的记录，可以看到已经删除的提交记录
2.2.什么是分支？
几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来进行重大的Bug修改、开发新的功能，以免影响开发主线。常用的分支相关的指令如下：
- git branch：查看本地分支
- git branch 分支名：创建本地分支
- git checkout 分支名：切换分支
- git checkout -b 分支名：可以直接切换到一个不存在的分支（创建并切换）
- git merge 分支名称：一个分支上的提交可以合并到另一个分支
- git branch -d b1：删除分支时，需要做各种检查**（不能删除当前分支，只能删除其他分支）**
- git branch -D b1：不做任何检查，强制删除 （不能删除当前分支，只能删除其他分支）
2.3.Git操作远程仓库
虽然Git会把代码以及历史保存在本地，但最终还是要提交到服务器上的远程仓库。通过clone命令可以把远程仓库的代码下载到本地，同时也会将提交历史、分支、HEAD等状态一并同步到本地，但这些状态并不会实时更新，需要手动从远程仓库去拉取。常用的相关的指令如下：
- git remote add <远端名称> <仓库路径>：添加远程仓库，此操作是先初始化本地库，然后与已创建的远程库进行对接，远端名称，默认是origin，取决于远端服务器设置仓库路径，从远端服务器获取此URL
- git remote：查看远程仓库
- git push [-f] [--set-upstream] [远端名称 [本地分支名][:远端分支名] ]：推送到远程仓库
如果远程分支名和本地分支名称相同，则可以只写本地分支。其中：-f 表示强制覆盖、--set-upstream 推送到远端的同时并且建立起和远端分支的关联关系。
- git push：将master分支推送到已关联的远端分支。
- git branch -vv：查看本地分支与远程分支的关联关系
- git clone <仓库路径> [本地目录]：从远程仓库克隆到本地（本地目录可以省略，会自动生成一个目录）
**从远程仓库中抓取和拉取：**远程分支和本地的分支一样，我们可以进行merge操作，只是需要先把远端仓库里的更新都下载到本地，再进行操作：
- git fetch [remote name] [branch name]：抓取指令就是将仓库里的更新都抓取到本地，不会进行合并（如果不指定远端名称和分支名，则抓取所有分支）
- git pull [remote name] [branch name]：拉取指令就是将远端仓库的修改拉到本地并自动进行合并，等同于fetch+merge（如果不指定远端名称和分支名，则抓取所有并更新当前分支）
GitFlow
Git Flow是一种在Git版本控制系统中使用的分支管理工作流程，这个工作流程围绕着工程（project）的发布（release）定义了一个严格的如何建立分支的模型。它定义了一套严格的分支命名规则和分支合并策略，以帮助团队更好地协作开发和管理代码。
1. GitFlow如何工作？
Git Flow的关键概念包括：
- 主干分支（master）：用于存放稳定的、可发布的代码版本，只能从其他分支合并，不能直接修改；
- 开发分支（develop）：用于集成各个功能开发分支的代码，是开发团队的主要工作分支，包含所有要发布到下一个 Release 的代码，该分支主要合并其他分支内容；
- 功能分支（feature）：用于开发新功能的分支，基于develop分支创建，开发新功能，待开发完成后再合并回develop分支；
- 发布分支（release）：用于发布新版本的分支，基于 Develop 分支创建，待发布完成后合并到 develop 和 master分支，并打上版本号标签。
- 修复分支（hotfix）：用于修复线上问题的分支，基于master分支创建，待修复完成后合并到develop和master分支，同时在master上打一个标签。
2.GitFlow的各分支及工作原理
GitFlow的核心就是分支(Branch），通过在项目的不同阶段对分支的不同操作（包括但不限于创建、合并、变基等）来实现一个完整的高效率的工作流程。Git Flow模型中定义了主分支和辅助分支两类分支。其中主分支包含主要分支（master）和开发分支（develop），用于组织与软件开发、部署相关的活动；辅助分支包含功能分支（feature）、发布分支（release）、热修复分支（hotfix）以及其他自定义分支，辅助分支是为了解决特定的问题而进行的各种开发活动，与主分支不同，这些分支总是有有限的生命时间，因为它们最终将被移除。
2.1.主干分支
主分支（master）：主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。任何时候在这个分支获取到的都是稳定的已发布的版本。各个版本通过tag来标记，如下图的v0.1和v0.2就是tag。
2.2.开发分支
开发分支（develop）：开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。该分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。
2.3.功能分支
功能分支（feature）：一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。注意：功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃，feature分支永远不会和master分支打交道。如下图：
2.4.发布分支
发布分支（release）：一般命名为 Release/1.2（后面是版本号），该分支专为测试---发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。预发分支只能拉取自开发分支，合并回开发分支和主要分支。如下图所示：
2.5.热修复分支
热修复分支（hotfix）：一般命名为Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责代码修复的人并行、独立的开展工作。热修复分支只能从主要分支上拉取，测试通过后合并回主要分支和开发分支。如下图：
总之，Git Flow通过规范化的分支管理和合并流程，实现了软件开发过程中的协同合作、版本控制和错误修复等功能。这种工作流模式有助于提高开发效率和产品质量。目前我们经常利用GitFlow进行日常开发：开发者通常在 develop 分支上工作，当需要开发新特性时，他们会创建一个特性分支feature；合并特性：当特性开发完成后，特性分支feature被合并回 develop 分支；准备发布：当 develop 分支上的功能足够多时，创建一个 release 分支来准备下一个版本；发布版本：发布分支经过最终测试后，将其合并到 master 和 develop 分支，并打上标签；紧急修复：如果在master 分支发现错误，创建 hotfix 分支，修复后合并回master 和 develop等。