工作中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更加游刃有余