Git Guide

Posted 2021-09-27 -飞鹤-

1. Intro

Git 是一个开源的分布式版本控制系统。由于其分布式的特点，每一台安装Git系统的电脑都可以有所有代码的完整仓库信息。但是开发人员并不关心与他无关的代码工程、代码分支等，开发人员只需要同步自己相关的工程即可。

2. Install

从Git官网下载最新版本Git软件。安装过程中，可以更换安装目录，其他的安装选项均为默认即可。

3. Git VS SVN

• Git是分布式的，即每台安装系统的电脑都是一个完整的版本记录，即便没有网络，也可以查看版本上传记录；SVN是集中式的版本系统，完整的版本信息都记录在服务器上，查询版本信息必须连接服务器。
• Git有本地仓库和远程仓库两个仓库。日常的版本管理在本地仓库中进行，执行效率更高。在本地版本进行了基本的验证之后，同步远程仓库的最新版本信息，再次验证代码之后，便可以Push到远程仓库。SVN的每次版本信息都需要提交到远程仓库。
• SVN有一个全局的版本号，而Git没有全局的版本号，Git是靠每个版本的快照校验值SHA-1来标识版本信息的。
• Git采用Hash算法保证每个版本的完整性，而SVN没有。
• Git是分布式的，并且有Hash算法保证完整性，每一个Project至少有两台电脑存放完整版本信息(远程服务电脑和开发电脑），所以Git的远程服务不需要像SVN那样进行备份来保证安全性。
• Git的日志是基于本地仓库的，访问速度更快，但不是自动与服务仓库同步，需要手动Pull之后才与服务仓库同步；SVN的日志是基于服务仓库的，是实时的。
• Git和SVN分支的概念不一样。SVN的分支是一个继承自指定版本的新的目录。因为Git的仓库分为本地仓库和远程仓库，所以分支也分为本地分支和远程分支。Git的分支之间的关系是平行，不同分支可以随意互相合并。
• Git和SVN的Tag概念也不一样。SVN的Tag是一个特殊分支，而Git中的Tag则是某个分支的某次提交的一个标签。

4. Concept

1. main，Git中没有trunk的概念，所有的都是branch，但是会将第一个branch标记为main(注：几年前是用2. master，后来防止有歧视的意思改为main)。
2. push，即将本地仓库的版本记录推送到远程仓库的对应分支。
3. pull，即从远程仓库拉取项目的对应分支的最新版本与本地版本进行合并，当前版本标签更新到最新。
4. fetch，即从远程仓库获取对应分支的最新版本信息到本地仓库，但是工作目录的内容不会更新。
5. clone，即从远程仓库获取对应项目的所有版本信息。
6. index，可以理解为暂存区。
7. add，是将文件添加到暂存区。
8. commit，是将修改上传到本地仓库中，本地仓库也会有完整的日志记录。
9. checkout，即从本地仓库检出需要修改的分支，如果是远程分支会创建相应的本地分支。
10. ignore，每个Git项目中都需要一个“.gitignore”文件，用来标识当前项目中哪些文件不用上传。文件规则见官方文档。
11. stash，将当前未commit的修改存放在堆栈入，需要使用时pop出来即可。
    tag，某个分支的某次关键提交的标签，甚至可以说是别名，通过tag可以更方便地找到指定分支的指定提交版本。
12. submodule，项目中如果需要使用到他人维护的项目，可以设置submodule来引入他人的项目。
13. hook，用于扩展相关功能，每次commit前后可以调用相关脚本程序，执行发邮件、启动CI等功能。
14. bisect，二分法切换代码版本。指定代码版本范围，一个命令即可完成二分法代码版本切换。

5. branch

Git是分布式的，每台接入Git系统的电脑都有一个完整版本信息的仓库。

• Git的远程仓库，默认称为origin，仓库中新建项目的第一个分支称为main分支。
• 开发电脑上的仓库，称为本地仓库，在Clone远程仓库的项目到本地目录之后，会在本地默认创建一个main分支，并且本地的main分支关联远程的origin/main，关联远程分支的本地分支也被称为跟踪分支(Tracking Branch)。
• 在Pull远程分支之后，跟踪分支会自动与跟踪的远程分支进行合并，可以取消本地分支与远程分支之间的跟踪关系。
• 将远程项目Clone到本地的两个目录，那么就存在两个本地仓库，两个本地仓库的分支是互相不影响的。
• 在本地仓库创建独立的本地分支，本地分支功能完成之后，可以合并到开发分支，然后可以删除。
• 本地分支也可以推送到远程仓库，并且会在远程仓库创建对应的远程分支。
• 本地仓库可以关联多个远程仓库，分地分支可以分别或同时推送到多个远程仓库的相应分支。

6. merge vs rebase

• merge是合并指定分支，pull操作相当于fetch和merge两个操作。feature分支是从master分支分出去的，开发完成之后又合并进master分支。merge命令如果带–no-ff参数，则合并之后的分支日志记录不会合并到main分支。git的分支合并非常强大，可以合并本地与本地的分支，可以合并远程与本地的分支，可以合并远程与远程的分支，甚至可以合并不同仓库的远程分支。
  
• rebase，修改当前分支的起始位置为指定分支的最新位置。rebase之后日志的记录是线性的，更有利于回归版本。
  

7. Operating Flow

8. Workflow

Git提供了非常基础的代码管理功能，可以适用于不同的版本管理工作流。

8.1. Integration-Manager Workflow

此流程是git官方推荐的流程之一。

1. 项目维护者推送到主仓库。
2. 贡献者克隆此仓库，做出修改。
3. 贡献者将数据推送到自己的公开仓库。
4. 贡献者给维护者发送邮件，请求拉取自己的更新。
5. 维护者在自己本地的仓库中，将贡献者的仓库加为远程仓库并合并修改。
6. 维护者将合并后的修改推送到主仓库。
   注：远程开发仓库，根据情况可以使用fork来完成，也可以本地仓库关联多个远程仓库进行推送完成。
   

8.2. Git Branching Model Flow

此开发流程最早由Vincent Driessen提出，后来获得众多开发人员认可。很多开源代码使用此方式。如果参与提交代码的开发人员众多，会以此流程结合Interration-Manager Workflow来完成。可信度高的人使用Shared Repository来维护主要的远程仓库。可信度低的人Fork出代码进行开发，然后通知可信度高的人来合并他的代码进主要远程仓库的分支。

1. master分支，即main分支，此分支只用来合并稳定的发布版本，并加上相应的版本Tag。
2. hotfix分支，用来修改main分支的Bug，修复完之后，立即合并到main分支，并打上相应Tag。
3. release分支，用来准备发布的分支版本，此分支不再添加新功能，只用来修复测试中的Bug，稳定后并到main分支，并打上相应Tag。
4. develop分支，多人协作开发的分支，主要的维护分支，在想发版本之后，在此分支基础上创建Release分支。未完成的短期(一周以内)修改，建议上传至本地分支，修改完成之后推送到远程develop分支。立即完成的修改，可以随时提交到本地分支并推送到远程分支。需要长期开发的功能，被认为是Feature，可以创建Feature分支进行开发。其他不定是否合并的长期修改，可以Fork一个仓库，可以推送到本人公开仓库进行维。
5. feature分支，需要长期开发的功能，都可以从develop分支创建新的分支进行开发，开发完成之后合并到develop分支。
   注：任何合并之后且不再使用的分支，都建议删除，太多分支影响分支切换的便利性。
   

8.3. Lightweight Git Flow

Git Branching Model Flow相对有些复杂，借鉴Github Flow(Github推荐的，相对轻量级的Git Flow，但是GitHub有Pull Request功能，GetLab没有此功能，但是merge功能可以达到效果)整理了如下的Lightweight Git Flow，相对轻量级，使用更简单些。将Git Branching Model Flow中的main/hotfix/release三个分支合并为一个。