Git进阶-温故知新系列

5次阅读

共计 4670 个字符，预计需要花费 12 分钟才能阅读完成。

日常开发中用的最多的是 git add、git commit、git pull、git fetch、git push 等，不过当出现一些稍复杂一点的场景，如果具备相应的 git 知识储备，就很有可能脱颖而出。本文首先阐述 git 的一些基本原理，然后对开发中比较常遇到的合并和撤销等场景做讲解，避免死记硬背。

版本控制工具采用的存储方式：

存储差异：存储 base 文件，之后的版本存储 base 文件的更改，SVN
存储快照：每次更改都存储一个新文件，Git（类似于 immutable 的原理?）

先来认识下 .git 目录下几个比较重要的文件:

config：仓库的配置文件
HEAD：当前所在的位置，指向具体分支
refs/：存储的是引用文件，如本地分支，远端分支，标签等（其内容为 40 位 hash，指向 commit 节点）objects/：数据文件的存储目录
hooks/: 钩子目录，在特定的重要动作发生时触发自定义脚本

这里重点介绍下 objects，仓库中每个文件都有对应的 hash 值，包括 3 种数据类型：文件（blob）、文件夹（tree）、提交（commit），其内容分别如下：

1. blob 文件：具体文本
2. tree 文件：100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
3. commit 文件：tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
    author Scott Chacon <schacon@gmail.com> 1243040974 -0700
    committer Scott Chacon <schacon@gmail.com> 1243040974 -0700

    first commit

可以看到，git 对文件的管理是通过记录的文件 hash，然后通过 hash 查找对应文件内容的方式。
最后看一张 git 仓库的原理图：

[注] HEAD：指向当前所在的分支；ref/head/：指向当前的 commit 版本；ci：commit 节点，包含当前版本的文件引用

理解 commit 节点间的引用关系，对理解分支的新建、切换、合并、撤销等至关重要。

由于每个分支 ref 指向的是 commit 节点，而 commit 通过 parent 指针指向前一次提交节点，实现链式提交记录的回溯

总结：git 操作时，关键还是指针的移动，这也是为什么 git 又名 – 内容寻址系统

理解了上面的基本知识，下面对合并和撤销操作做讲解就会简单很多。

// 合并某个提交
git cherry-pick <commitHash>
// 合并多个提交
git cherry-pick <HashA> <HashB>
// 合并连续提交 (不含 A)
git cherry-pick A..B
// 合并连续提交 (含 A)
git cherry-pick A^..B

代码冲突时：

1. 解决冲突
// 解决冲突后 git add .
git cherry-pick --continue
2. 退出合并
git cherry-pick --abort

merge

git merge [待合并的分支名]
# 3 种模式
-fast-forward：默认方式，如果待合并的分支在当前分支的下游，即也就是说没有分叉时，会发生快速合并
–no-ff：在当前分支上新建一个提交节点，从而完成合并
–squash：和 no-ff 非常类似，区别只有一点不会保留对合入分支的引用

代码冲突时：

1. 解决冲突
// 解决冲突后 git add .
git commit -m 'xx'
2. 退出合并
git merge --abort

rebase

git rebase [作为合并基准的分支名]
// 一般使用：比如 feature 要合并到 master
1）先在 feature 分支 rebase master，即将 feature 的提交应用到 master 节点后
2）再 checkout 到 master 使用 merge 移动 master 指针到最新节点 (fast-forward)

代码冲突时：

1. 解决冲突
// 解决冲突后 git add .
git rebase --continue
2. 退出合并
git rebase --abort

两者的区别

假定当前分支情况如下

   {master}
      |
A--B--C
   |
   D--E
      |
  {feature}

merge
1）合并待合并分支的提交信息后，生成一个新的提交节点
2）保留分支的提交合并记录，便于掌握历史操作记录

// 在 master 分支使用 merge
feature> git merge master

      {master}
         |
A--B--C--F
   |    /
   D--E
      |
  {feature}

rebase
1) 指定目标分支作为基准点，将当前分支的节点依次 patch 到目标分支最新提交后
注意这里仅改变了待合并分支的指针位置，需要 checkout 到目标分支使用 merge，则会直接将目标分支指针移动到最新提交节点
2) 不会删除或复用待合并的提交，而是依次创建新的提交应用到目标分支
3) 不会保留合并记录，使得提交记录线性化

// 在 feature 分支使用 rebase
feature> git rebase master

  {master} {feature}
      |      |
A--B--C--D'--E'
   |
   D--E

至于在开发中是何时使用 merge，何时使用 rebase，这个见仁见智。（个人觉得主分支保持清爽很重要，但是特殊情况下撤销 merge 的分支合并更方便）

// 使用暂存区内容覆盖工作区
git checkout -- fileName

reset

主要用途： 回退版本内容
一般格式

git reset <option> < 版本 >

常用 option

--hard: // 使用指定的提交版本覆盖工作区和暂存区。即删除指定版本后的所有提交内容
--soft：// 将指定提交之后的内容回退到暂存区，工作区不变动
--mixed: // 将指定提交之后的 commit 以及暂存区的内容退回到工作区未保存状态

对于本地仓库，都是指针的变更；文件或要舍弃（hard），或要合并提交（soft），或要修改（mixed）

举例
git reset 命令既可以回退版本，也可以把暂存区的修改回退到工作区

// 把所有暂存区中的修改回退到工作区未保存状态 git reset HEAD   // 默认为 --mixedgit rest HEAD file

回退版本的指定

HEAD^: 上一个版本 HEAD^^：上上一个版本...HEAD~n: 比如回退到倒数第 3 个版本，HEAD~3

回退版本后，想要提交到远程仓库，则需要使用 -f 强推：

push -f -u origin master

如果回退版本后，想要回到撤销前的版本，则可以使用 git reflog 查看对应的 commitId。git reflog 会列出所有历史提交记录，和 git log 的差异在于包含删除的提交记录

git reset --hard HEAD@{N}

revert

主要用途：撤销某个提交操作

1) 撤销某个普通 commit

对指定的 commit 进行撤销操作，生成一个新的提交记录

git revert <commitId>

2) 撤销某个 merge commit

先来看合并两个分支后生成的 commit 节点信息

git show cs38864
commit bd868465569400a6b9408050643e5949e8f2b8f5
// 有两个 parant commit，指明当前 commit 节点由哪两个 commit 合并
Merge: ba25a9d 1c7036f

执行撤销时，需要指定主线分支，将会撤销另一分支内容

/**   
 *- m 表示是一个 merge 节点  
 *parent-number：1 | 2 表示保留哪个 parent 节点，顺序为上例中 Merge 中的 commit
 **/
 git revert -m parent-number <commitId>

对于撤销的合并分支上的提交，后续再合并，撤销的节点也不会被合并；想要将撤销的分支提交重新合并，需对 revert 生成的 commit 进行一次撤销。

两者的区别

1.revert：不会删除提交记录，保留每一步操作记录，更安全  
  reset：不包含已删除的合并提交    
2.revert 因为是对指定提交进行取反操作，创建一个新的提交，因此无需强推到远程仓库    
3. 建议：本地 reset，公共分支 revert    
4. 合并后如果做了操作，reset 到合并节点前，会删除之后的提交信息；可以使用 reset 达到 revert 的效果，如下：// 回退提交内容到工作区  
  git reset devb-3  
  // 将工作区的内容暂存 stash  
  git stash  
  // 使用 hard 改变（删除）指针 commit  
  git reset --hard devb-2  
  // 恢复 stash 的内容到工作区  
  git stash pop  
  // 提交  
  git add & commit & push

1. 对上一次提交进行修改 (打补丁)，会创建一个新的 commitId

git commit --amend
// 修改提交信息
git commit --amend -m 'xxx'
// 代码逻辑的修补
git commit --amend –-no-edit

2. 合并多个提交记录
方式 1

git reset --soft commitId  // 将制定 commit 后的提交信息回退到暂存区
git commit -m '合并多个 commit'

方式 2

# (start-commit, end-commit] 前开后闭区间，默认 end-commit 为当前 HEAD
git rebase -i [start-commit] [end-commit]

3. 查看不同阶段代码的差异

git diff: 查看工作区和暂存区的差异
git diff --cached HEAD：暂存区和当前仓库指针的差异

4.git stash

将工作区和暂存区的内容存储起来；默认状态，git stash 命令会将工作区和暂存区内容重置为最近一次提交后的内容，并且只能将已经跟踪和非.gitignore 忽略的文件储藏，未跟踪的文件不会被存储。如果想要将未跟踪的文件一并存储，使用 -u（--include-untracked）

git stash push -u

The latest stash you created is stored in refs/stash; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. stash@{0} is the most recently created stash, stash@{1} is the one before it, stash@{2.hours.ago} is also possible). Stashes may also be referenced by specifying just the stash index (e.g. the integer n is equivalent to stash@{n}).

git stash pop // 取出栈顶的暂存信息
git stash list // 查看暂存区的所有暂存修改
git stash apply stash@{X} // 取出相应的暂存；不会向 pop 一样从栈中移除 stash
git stash drop stash@{X} // 将记录列表中取出的对应暂存记录删除

获取更多干货分享，欢迎【扫码关注】~

参考：
https://dotblogs.com.tw/wasic…
https://www.liaoxuefeng.com/w…
https://zhuanlan.zhihu.com/p/…
https://yanhaijing.com/git/20…

正文完

javascript

发表至： javascript

2020-06-20

0

2019商业智能报表工具的全方位剖析

精读前端未来展望

关于javascript:简单实现一个requireJS

关于javascript:手撕JS可能持续更新

深入浅出javascript-5-闭包

Git进阶-温故知新系列

前言

内部原理

合并

部分提交

全部提交

merge

rebase

两者的区别

撤销

工作区内容撤销

暂存区内容撤销

reset

revert

两者的区别

拾遗

站内搜索