版本控制

Git是什么
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency

版本控制是什么？
一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统

为什么需要版本控制？
更好的关注变更，了解到每个版本的改动是什么，方便对改动的代码进行检查，预防事故发生；也能够随时切换到不同的版本，回滚误删误改的问题代码；

版本控制类型	代表性工具	解决的问题
本地版本控制	RCS	本地代码的版本控制
集中式版本控制	SVN	提供一个远端服务器来维护代码版本，本地不保存代码版本，解决多人协作问题
分布式版本控制	Git	每个仓库都能记录版本历史，解决只有一个服务器保存版本的问题

本地版本控制

最初的方式
通过本地复制文件夹，来完成版本控制，一般可以通过不同的文件名来区分版本

解决方案
开发了一些本地的版本控制软件，其中最流行的是 RCS

基本原理
本地保存所有变更的补丁集，可以理解成就是所有的 Diff，通过这些补丁，我们可以计算出每个版本的实际的文件内容

缺点
RCS 这种本地版本控制存在最致命的缺陷就是只能在本地使用，无法进行团队协作，因此使用的场景非常有限，因此衍生出了集中式版本控制

集中版本控制

代表性工具: SVN
基本原理:

提供一个远端服务来保存文件，所有用户的提交都提交到该服务器中
增量保存每次提交的 Diff，如果提交的增量中和远端现存的文件存在冲突，则需要本地提前解决冲突

优点:

学习简单，更容易操作
支持二进制文件，对大文件支持更友好

缺点:

本地不存储版本管理的概念，所有提交都只能联上服务器后才可以提交
分支上的支持不够好，对于大型项目团队合作比较困难
用户本地不保存所有版本的代码，如果服务端故障容易导致历史版本的丢失。

分布式版本控制

代表性工具: Git
基本原理:

每个库都存有完整的提交历史，可以直接在本地进行代码提交
每次提交记录的都是完整的文件快照，而不是记录增量
通过 Push 等操作来完成和远端代码的同步

优点:

分布式开发，每个库都是完整的提交历史，支持本地提交，强调个体
分支管理功能强大，方便团队合作，多人协同开发
校验和机制保证完整性，一般只添加数据，很少执行删除操作，不容易导致代码丢失

缺点:

相对 SVN 更复杂，学习成本更高
对于大文件的支持不是特别好（git-lfs 工具可以弥补这个功能）

Git 目录介绍

项目初始化
mkdir study
cd study
git init
其他参数
--initial-branch 初始化的分支
--bare 创建一个裸仓库 (纯 Git 目录，没有工作目录)
--template 可以通过模版来创建预先构建好的自定义 git 目录

不同的工作流

类型	代表平台	特点	合入方式
集中式工作流	Gerrit / SVN	只依托于主干分支进行开发，不存在其他分支	Fast-forward
分支管理工作流	Github / Gitlab	可以定义不同特性的开发分支，上线分支，在开发分支完成开发后再通过 MR/PR 合入主干分支	自定义，Fast-Forward or Three-Way Merge 都可以

集中式工作流

什么是集中式工作流？
只依托于 master 分支进行研发活动
工作方式

获取远端 master 代码
直接在 master 分支完成修改
提交前拉取最新的 master 代码和本地代码进行合并 (使用 rebase)，如果有冲突需要解决冲突
提交本地代码到 master

集中式工作流-Gerrit

优点

提供强制的代码评审机制，保证代码的质量
提供更丰富的权限功能，可以针对分支做细粒度的权限管控
保证 master 的历史整洁性
Aosp 多仓的场景支持更好

缺点

开发人员较多的情况下，更容易出现冲突
对于多分支的支持较差，想要区分多个版本的线上代码时，更容易出现问题
一般只有管理员才能创建仓库，比较难以在项目之间形成代码复用，比如类似的 fork 操作就不支持。

分支管理工作流

分支管理工作流	特点
Git Flow	分支类型丰富，规范严格
Github Flow	只有主干分支和开发分支，规则简单
Gitlab Flow	在主干分支和开发分支之上构建环境分支，版本分支，满足不同发布 or 环境的需要

Git相关 | 青训营笔记