工作中Git 使用心得笔记
Git 是一个分布式版本控制系统（DVCS）
什么是版本控制系统（VCS）
版本控制系统（Version Control System）最基本的功能是版本控制。就是在文件的修改历程中保留修改历史，让你可以方便地撤销之前对文件的修改操作
什么是分布式版本控制系统（DVCS）
分布式和中央式的区别在于，分布式除了有中央仓库之外，还有本地仓库，团队中每一个成员的机器上都有一份本地仓库，这个仓库里包含了所有的历史版本,成员可以在无需联网情况下可以和本地仓库交互
优点：
- 大多数操作本地操作，速度会更快
- 可以在不联网情况下，提交代码、切换分支、查看历史
缺点：
- 每个成员机器需要完整的本地仓库，初次clone会耗时，且本地占用存储会比中央式要高
- 对于有大量大尺寸文件或媒体文件，并且文件格式不容易压缩，采用分布式会导致仓库体积非常庞大，所以大型游戏开发建议选择中央式VCS管理
常用操作指令
// 远程仓库拉取到本地
git clone xxx.git
// 查看git提交信息
git log
// 查看工作目录当前状态
git status
// 提交某个文件至暂存区
git add a.js
// 全部提交至暂存区
git add .
// 提交某个文件目录下所有文件至暂存区
git add list/
// 提交
git commit
// 修改最新的commit错误内容（只针对本地仓库有效，已经push到中央仓库要执行push -f）
git commit --amend
// 拉取远程仓库代码
git pull
// 本地分支代码同步到远程
git push
// 新建分支并切换到该分支
git checkout -b feature1
// 本地分支push到远程
git push origin feature1:feature1
// 基于远程仓库分支创建本地分支
git checkout -b feature1 origin/feature1
// 删除分支(删除分支，当前分支不能在要删除的分支上)
git branch -d feature1
// 删除远程分支
git push origin --delete feature1
merge VS rebase
merge
git merge 会让2个分支的提交按照提交时间进行排序，并且会把最新的2个commit合并成一个commit。最后的分支树呈现非线性的结构
执行前,如下图 
执行git merge branch1后,如下图 
查看history历史，如下图 
rebase
rebase 是站在需要被 rebase 的 commit 上进行操作，这点和 merge 是不同的
git reabse 将dev的当前提交复制到master的最新提交之后，会形成一个线性的分支树
执行前,如下图
执行rebase操作
git checkout branch1
git rebase master
在 rebase 之后，切回 master 再 merge 一下，把 master 移到最新的 commit
git checkout master
git merge branch1
如何修改不是最新提交commit内容
git commit --amend 可以修复最新 commit 的错误，但如果是倒数第二个 commit 写错了呢？
rebase -i
rebase -i 是 rebase --interactive 的缩写形式，意为「交互式 rebase」
意思是在rebase 的操作执行之前，你可以指定要 rebase 的 commit 链中的某一个 commit 是否需要进一步修改，利用这个特点，进行一次「原地 rebase」
git rebase -i HEAD^^
// 等同于
git rebase -i HEAD~2
注意：在 Git 中，有两个「偏移符号」： ^ 和 ~
-
^用法:
- 在 commit 的后面加一个或多个 ^ 号，可以把 commit 往回偏移，偏移的数量是 ^ 的数量，例如：HEAD^^ 表示 HEAD 所指向的 commit 往前数两个 commit
-
~用法:
- 在 commit 的后面加上 ~ 号和一个数字，可以把 commit 往回偏移，偏移的数量是 ~ 号后面的数字。例如：HEAD~3 表示 HEAD 指向的 commit往前数 3 个 commit。
执行git log，修改倒数第二个commit，把修改about文件111替换为修改about文件222
1、执行
git rebase -i HEAD~2
如图： 
注意：这时展示顺序是要修改的最上面，新的在最下面，点击i,进入vim编辑模式，把第一个pick 修改为edit,点击Esc,退出vim编辑模式，点击shift + 分号，输入wq保存退出即可
当前git链如图：
2、执行
git commit --amend
修改内容为‘修改about文件222’ 
3、保存退出后，执行
git rebase --continue
在修复完成之后，就可以用 rebase --continue 来继续 rebase 过程，把后面的 commit 直接应用上去。
执行git log,如图，已经修改成功
版本回退
git reset的本质：移动HEAD以及它所指向的branch
- --hard
清空工作区与缓存区,应用场景是放弃目标版本后所有的修改
$ git reset --hard commitHash
恢复至commitHash版本，删除commitHash之后工作区和缓存区的修改
- --soft
保留工作区与缓存区，但是把版本之间的差异存放在缓存区
git reset --soft HEAD^
恢复上一个版本，保留工作区，缓存区准备再次提交commit
合并多个commit
git rebase -i HEAD~n
n:代表要合并的commit个数
将要合并的提交pick改为s(squash) 
修改完毕后，按esc退出编辑，按wq保存并退出
开发到一半，临时切换到其他分支
例如正在feature分支开发新功能，突然线上出现bug，需切换到hotfix分支修复bug
git stash这个命令可以将当前的工作状态保存到git栈，在需要的时候再恢复
1、执行git stash
git stash
2、切换其他分支开发，当切回来后
// 查看当前stash的所有内容
git stash list
3、将堆栈中的内容恢复到当前分支下
git stash apply stash@{$num}
如放弃存在栈中内容，执行git stash drop stash@{$num}
git 版本打标签
tag 就是 对某次 commit 的一个标识，相当于起了一个别名
git tag 标签名
// or
git tag 标签名 提交版本号
// 删除标签
git tag -d 标签名称
// 推送到远程仓库
$ git push origin 标签名称
or
$ git push origin --tags
cherry-pick
把指定的commit，拉到一个新的分支上
例如在某个稳定版本上，添加一个刚开发完成的feature版本中的某个功能。就可以使用 cherry-pick 命令，将这个功能相关的 commit 提取出来，合入稳定版本的分支上
git cherry-pick <commitHash>
git cherry-pick命令的参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交
git cherry-pick feature
cherry-pick 支持一次转移多个提交
git cherry-pick <commitHashA> <commitHashB>
如果操作过程中发生代码冲突，Cherry pick 会停下来，让用户决定如何继续操作,用户解决代码冲突后，使用--continue命令，让 Cherry pick 过程继续执行。
git cherry-pick --continue
总结
Git 内容非常多，本文只是列举出了工作中常用命令和使用方法，可能有些很有用的内容依然没有列举出来， 目的是希望在整个阅读过程中能够加深记忆，同时对未用过的命令加以练习，相信会在今后工作中使用git更加游刃有余