Why

• 版本管理
  • 记录若干文件变化内容，以便查阅版本修订情况
  • 更好的关注变更，控制代码版本
  • 常见的有RCS（本地），SVN（集中式），GIT（分布式）
• Git是一个免费、开源的用于高效管理小型/大型项目的分布式版本管理控制系统

Git最早是由Linus Torvalds因自身需求开发

• 集中式--SVN
  • 原理
    • 用远端服务来保存文件，用户提交到该服务器中
    • 增量每次保存DIFF，如果发生冲突，需要在本地提前解决冲突
  • 优点
    • 简单，支持二进制，对大文件友好
  • 缺点
    • 本地不存储版本概念，分支支持不足，服务器宕机容易造成代码丢失
• 分布式--Git
  • 原理
    • 每个库都有完整的提交历史
    • 每次提交都是文件完整快照，而不是记录增量
    • 通过push等操作来进行同步
  • 优点
    • 分布式开发，每个库都是完整的提交历史，强调个体
    • 功能强大，方便合作
    • 校验机制保证完整性，不容易代码丢失
  • 缺点
    • 学习成本高，对大文件支持不友好
• 几大主流代码托管平台
  • Github、Gitlan、Girrit

Git简介

命令

• 配置
  • 有不同级别的配置，低级别会覆盖高级别 global-->system-->local
  • git config
  • git remote
    • git remote add origin_ssh
      • 过去使用rsa，现在推荐使用ed25519进行非对称加密
      • ssh-keygen -他ed25519 -C "your_email@xx.com"
    • git remote add origin_http
    • 同一个元可以设置不同的push和fetch URL
  • 配置别名
• 提交
  • git add
  • git commit
  • git commit -amend 修改最近一次提交，commit ID会变化
    • 注意该操作之后会有悬空object可以通过GC回收
    • git GC删除一些object，并对一些object进行打包
    • git gc prune=now
    • Refflog用于记录操作日志，防止误操作
• 分支管理
  • git checkout -b 创建分支
  • git tag -a v0.0.1 -m "my version 0.1"
• 远程同步
  • 拉取
    • clone
    • pull == fetch and merge
    • fetch
  • 推送
    • push
      • 本地和推送的库历史不一致可能会发生冲突，如此需要修改/强制推送（不推荐）

管理方式

• git仓库在.git文件夹内
• git管理的文件分为工作区和暂存区
• git的Object
  • Blob存储文件内容
  • Tree存储文件目录信息
  • Commit存储提交信息,里面串联了Parent Commit
  • tag表示稳定的版本，指向的commit一般不会变更
• git通过Commit定位Tree，通过Tree信息获得目录树信息，并定位blob，通过blobID获取文件内容
• git的Refs
  • refs存储Commit ID
  • Refs/heads前缀表示的是分支，refs/tags表示的是标签

工作流

集中式工作流

• 只是依托于主干分支，不存在其他分支
• Fast-forward方式合入
• 工作流程
  • 获取远端master代码
  • 直接在master分支修改
  • 提交前拉取最新的master代码和本地代码合并，有冲突则解决冲突
  • 提交本地代码到master
• 优点
  • 提供强制代码评审机制，保证代码质量
  • 丰富的权限功能，对分支细粒度管理
  • 保证master的整洁性
  • Aosp多仓的场景支持更好
• 缺点
  • 人员较多，容易发生冲突
  • 分支支持交叉，需要区分多个版本线上代码，更容易出错
  • 管理员才能建立仓库，项目间难以代码复用，比如不支持类似的fork操作
• 缺点

分支管理工作流

• 定义不同特性的开发分支
• GitFlow
  • 定义了五种分支
  • 严格按照标准代码结构会很清晰
  • 流程复杂，不严格遵守容易造成混乱
• Github Flow
  • 自定义，fast-Forward or Three-Way Merge皆可
  • Github的工作流只有一个主干分支，基于Pull Request向主干分支中提交代码
  • 可以在Pull Request页面执行CI/CA/CR等操作，检查都通过后执行合入
  • 可以设置一些分支保护策略来限制合入策略以及限制直接push到主分支的操作
• Gitlab Flow
  • 在以上二者间做了平衡，保留单一分支的简便，又能适应不同开发环境
  • upstream first，只有上游分支采纳的代码才能进入下游分支，上游分支一般是master
• 代码合并
  • Fast-Forward
    • 不会产生一个Merge节点，合并后历史保持一个线性，如果目标分支有了更新，则要rebase之后才能merge
  • Three-Way Merge
    • 三方合并，产生一个新的Merge

总体来说各个工作流，都有不同的特点和特性，也适用于不同的团队和项目，在实际开发过程中可以根据需要选择适合的工作流和版本管理软件

针对小型团队Github是不错的选择，使用中推荐

1. 少量多次
2. PUll Request要进行检查，保证质量
3. 主干分支尽量干净，使用Fast-forward合入方式，合入前进行rebase

大型团队，则尽量根据需要设计，而不要局限于某种工作流或者方式