简介
分支操作
clone非master分支的代码
直接clone master分支，然后再git checkout -b new_branch，再git pull origin new_branch，这样就和本地操作一样了，会导致代码冲突。其实，git pull的时候，除了master分支，已经包括其它分支的数据了，直接git checkout new_branch 即可
$ git clone xx #克隆master分支
$ cd xx
$ git branch -a #查看所有分支
origin/HEAD -> origin/master
origin/daily/1.2.2
origin/daily/1.3.0
origin/daily/1.4.1
origin/develop
origin/feature/daily-1.0.0
origin/master
$ git pull origin master
$ git checkout new_branch
ok
回退
reset
git reset --hard commit_id(可用 git log –oneline 查看) ###本地代码回退
git push origin HEAD --force ###远程库代码回退
// 或者
git reset --hard HEAD~1
git push --force
revert
git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
git revert commitValue
commitValue可以使用git log查看
git协同工作流
来自陈皓《左耳听风》课程
- 中心式协同工作流
- 功能分支协同工作流，用分支来完成代码改动的隔离
-
gitflow协同工作流，开发、线上、预发和测试环境 都有对应的分支，要额外的精力管理好代码与环境的一致性。
环境 分支 来源 持续性 备注 线上 master hotfix/release 合并 长期 每一次提交都是可以发布的 线上 hotfix 预发 release developer 副本 功能开发完成 到 发布前 测试 developer feature 合并/release 合并 长期 开发 feature1, feature2 - github flow/forking flow，官方库 ==> fork 本地库 ==> 开发、push本地库 ==> 发起 pull request ==> 合并到官方库
- gitlab flow 将github flow 与环境联系起来
协同工作流的本质：基于分支来解决并发、版本和环境等问题。
- 不同的团队能够尽大可能的并行开发
- 不同软件版本和代码的一致性
- 不同环境和代码的一致性
- 代码总是会在稳定和不稳定间交替。我们希望生产线上的代码总是能对应到稳定的代码上来。
gitflow 是略显复杂的，在微服务及soa架构方式下，每个服务都很小，对应代码仓库都很小。以devops为主的开发流程、ci/cd 使得feture 代码在很短时间 便可以合并到master上，无需维护大量分支。因此协同工作流的本质，并不是怎么玩好代码仓库的分支策略，而是玩好我们的软件架构和软件开发流程。
- TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点
基本原理
从git底层命令开始说起
参见https://git-scm.com/book/zh/v1
git命令分为底层（plumbing）命令和高层（porcelain）命令，底层命令得以让你窥探 Git 内部的工作机制，也有助于说明 Git 是如何完成工作的，以及它为何如此运作。 多数底层命令并不面向最终用户：它们更适合作为新命令和自定义脚本的组成部分。
Git是一套内容寻址文件系统。 这种说法的意思是，Git 从核心上来看不过是简单地存储键值对（key-value）。它允许插入任意类型的内容，并会返回一个key，通过该key可以在任何时候再取出该内容。可以通过底层命令 hash-object 来示范这点，传一些数据给该命令，它会将数据保存在.git目录并返回表示这些数据的key,通过 cat-file 命令可以将数据内容取回。
$ mkdir test
$ cd test
$ git init
$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content
// 也可以直接添加文件
$ echo 'version 1' > test.txt
$ git hash-object -w test.txt
83baae61804e65cc73a7201a7252750c76066a30
$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
$ cat test.txt
version 1
存储的并不是文件名而仅仅是文件内容。这种对象类型称为 blob 。
$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
blob
Git 以一种类似 UNIX 文件系统但更简单的方式来存储内容。所有内容以 tree 或 blob 对象存储，其中 tree 对象对应于 UNIX 中的目录，blob 对象则大致对应于 inodes 或文件内容。通常 Git 根据你的暂存区域或 index 来创建并写入一个 tree 。因此要创建一个 tree 对象的话首先要通过将一些文件暂存从而创建一个 index 。
$ echo 'new file' > new.txt
$ git update-index --add new.txt
$ git write-tree
0155eb4229851634a0f03eb265b69f5a2d56f341
$ git cat-file -p 0155eb4229851634a0f03eb265b69f5a2d56f341
100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new.txt
commit对象
$ echo 'first commit' | git commit-tree d8329f（一个 tree 的 SHA-1）
fdf4fc3344e67ab068f836878b6c4951e3b15f3d
$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3（一个前继提交）
cac0cab538b970a37ea1e769cbbde608743bc96d
$ git cat-file -p fdf4fc3
tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
author Scott Chacon <schacon@gmail.com> 1243040974 -0700
committer Scott Chacon <schacon@gmail.com> 1243040974 -0700
first commit
commit指明了该时间点项目快照的顶层tree对象、作者/提交者信息（从 Git 设置的 user.name 和 user.email中获得)以及当前时间戳、一个空行，以及提交注释信息。
到这里，我们或许能理解git是一个内容寻址文件系统的含义。