devbox
小小林熬夜学编程
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Git版本控制管理——储藏和引用日志_git 储藏

作者：小小林熬夜学编程 | 2024-05-26 08:38:18

赞

踩

git 储藏

储藏

在开发中，会遇到很多优先级较高的任务，比如有紧急邮件需要马上处理，要召开临时紧急会议等，而如果每次被打断都需要重新从干净的工作目录重新开始开发，会严重拖慢工作效率，这种情况下，可以使用储藏(stash)。

一般说来，储藏可以捕获工作进度，并允许用户保存工作进度当重新进入开发时再次回到该进度，虽然可以使用分支和提交等操作来实现同等功能，但使用储藏方式更快捷。这有点像是游戏中保存进度的功能，以使用户在下次登陆的时候可以从上次的进度继续游戏。

而Git中的储藏可以通过简单的命令就全面彻底地捕获工作目录和索引，并且该功能能够使版本库是干净的，以执行后续的开发。也就是说使用储藏可以保证没有多余的提交或历史记录。

比如执行下面的命令初始化版本库：

  1. git init
  2.  
  3. echo abc > file1
  4. git add file1
  5. git commit -m "commit file1"
  6.  
  7. echo abcd > file2
  8. git add file2
  9. git commit -m "commit file2"

然后修改工作目录和索引，使之变为脏的：

  1. $ echo 1111 > file1
  2.  
  3. $ git add file1
  4. warning: LF will be replaced by CRLF in file1.
  5. The file will have its original line endings in your working directory
  6.  
  7. $ echo 2222 > file2
  8.  
  9. $ git status
  10. On branch master
  11. Changes to be committed:
  12.   (use "git restore --staged <file>..." to unstage)
  13.         modified:   file1
  14.  
  15. Changes not staged for commit:
  16.   (use "git add <file>..." to update what will be committed)
  17.   (use "git restore <file>..." to discard changes in working directory)
  18.         modified:   file2

此时如果要使用储藏保存工作目录和索引：

  1. $ git stash save
  2. warning: LF will be replaced by CRLF in file2.
  3. The file will have its original line endings in your working directory
  4. Saved working directory and index state WIP on master: 92ae186 commit file2
  5.  
  6. $ cat file1
  7. abc
  8.  
  9. $ cat file2
  10. abcd

从上面的结果显示可以看出，储藏之后的file1和file2会变成干净的。然后执行某个提交：

  1. echo 3333 > file3
  2. git add file3
  3. git commit -m "commit file3"

此时的版本库状态为：

  1. $ git status
  2. On branch master
  3. nothing to commit, working tree clean

之后再恢复储藏的内容：

  1. $ git stash pop
  2. On branch master
  3. Changes not staged for commit:
  4.   (use "git add <file>..." to update what will be committed)
  5.   (use "git restore <file>..." to discard changes in working directory)
  6.         modified:   file1
  7.         modified:   file2
  8.  
  9. no changes added to commit (use "git add" and/or "git commit -a")
  10. Dropped refs/stash@{0} (3fdc1951b447bfcd51032bbdbc17f5341f049de7)
  11.  
  12. $ git status
  13. On branch master
  14. Changes not staged for commit:
  15.   (use "git add <file>..." to update what will be committed)
  16.   (use "git restore <file>..." to discard changes in working directory)
  17.         modified:   file1
  18.         modified:   file2
  19.  
  20. no changes added to commit (use "git add" and/or "git commit -a")
  21.  
  22. $ cat file1
  23. 1111
  24.  
  25. $ cat file2
  26. 2222

可见在恢复储藏后，file1和file2均变为了未暂存的状态，虽然之前file1已经被暂存，但是恢复后的file1却与之前不同。

同时在git stash的保存中，虽然Git会为该操作添加默认的日志信息，但其实用户也是可以自己添加日志信息的：

git stash save "memo message"

在开发中，若使用分支和提交机制模拟中断处理机制，整个过程就是创建临时分支，检出到该分支，然后提交所有未完成的修改，回到主分支，进行紧急处理，然后检出之前的临时分支，继续中断的操作。不过该过程在保存状态时，所有变更都要捕获，同时临时分支的也要正确检出，否则整个还原过程就会出错。

而git stash save命令将保存当前索引和工作命令的状态，并且会将之清楚以匹配当前分支的HEAD。索引和工作命令的内容实际上另存为独立且正常的提交，其可以通过refs/stash来查询：

  1. $ git show-branch stash
  2. [stash] WIP on master: 450aae2 commit file3

而储藏之后的内容提取则是通过git stash pop进行，从命令形式可以看出，pop的意思是出栈，那么便可能存在多个储藏的入栈，出栈：

  1. $ git stash save
  2. Saved working directory and index state WIP on master: 450aae2 commit file3
  3.  
  4. $ cat file1
  5. abc
  6.  
  7. $ cat file2
  8. abcd
  9.  
  10. $ echo 4444 > file1
  11.  
  12. $ git stash save
  13. warning: LF will be replaced by CRLF in file1.
  14. The file will have its original line endings in your working directory
  15. Saved working directory and index state WIP on master: 450aae2 commit file3
  16.  
  17. $ cat file1
  18. abc
  19.  
  20. $ git stash pop
  21. On branch master
  22. Changes not staged for commit:
  23.   (use "git add <file>..." to update what will be committed)
  24.   (use "git restore <file>..." to discard changes in working directory)
  25.         modified:   file1
  26.  
  27. no changes added to commit (use "git add" and/or "git commit -a")
  28. Dropped refs/stash@{0} (7da0998acce71b85931a8a10e1353b29153739e6)
  29.  
  30. wood@DESKTOP-NVKVULV MINGW64 ~/Desktop/GIT/tmp (master)
  31. $ cat file1
  32. 4444
  33.  
  34. $ git stash pop
  35. error: Your local changes to the following files would be overwritten by merge:
  36.         file1
  37. Please commit your changes or stash them before you merge.
  38. Aborting
  39. The stash entry is kept in case you need it again.
  40.  
  41. $ git restore file1
  42.  
  43. $ git restore file2
  44.  
  45. $ cat file1
  46. abc
  47.  
  48. $ cat file2
  49. abcd
  50.  
  51. $ git stash pop
  52. On branch master
  53. Changes not staged for commit:
  54.   (use "git add <file>..." to update what will be committed)
  55.   (use "git restore <file>..." to discard changes in working directory)
  56.         modified:   file1
  57.         modified:   file2
  58.  
  59. no changes added to commit (use "git add" and/or "git commit -a")
  60. Dropped refs/stash@{0} (3d497bcef240e221c73ba9a7eff8e97dcc159eeb)
  61.  
  62. $ cat file1
  63. 1111
  64.  
  65. $ cat file2
  66. 2222

上面的代码共有几个过程：

  • 首先当前的工作目录和索引是脏的，执行git stash save，此时的工作目录和索引变为干净的
  • 然后重新将file1变为脏的，同时再次执行git stash save，此时的工作目录和索引有变为干净的
  • 中间不做任何操作，以表示中间可能发生的任何有效操作
  • 然后执行git stash pop，此时最近的储藏会被提出，file1中的内容也变为脏的
  • 而若在工作目录或索引为脏的情况下，是不能使用git stash pop的，这表明该命令需要在工作目录或索引为干净的操作下执行
  • 在file1，file2变干净之后，执行git stash pop，此时提出的是第一次git stash save保存的内容，而工作目录和索引也变为了脏的

同时在一个pop操作成功后，Git会自动地将储藏状态栈中保存的状态删除，也就是说，储藏的状态会被丢弃。然而，当需要解决冲突时，Git不会自动丢弃状态，以便用户自己手动处理，而在冲突处理后继续操作则应使用git stash drop来将状态从储藏栈中删除，否则，Git将会维持一个内容不断增加的栈。

而如果想要重新创建一个已经保存在储藏栈中的上下文，又不想把它从栈中删除，那么就可以使用git stash apply，也就是说，pop命令实际是apply和drop的封装。

又因为储藏捕获的实际是工作目录和索引，因此若在save操作后直接执行drop也会删除捕获的工作目录和索引的内容，即此时的工作目录和索引会重新变为干净的。

同时还有个简单的命令git stash list，用来按照时间顺序列举储藏栈：

  1. $ git status
  2. On branch master
  3. nothing to commit, working tree clean
  4.  
  5. $ echo 1111 > file1
  6.  
  7. $ git stash save "first stash"
  8. warning: LF will be replaced by CRLF in file1.
  9. The file will have its original line endings in your working directory
  10. Saved working directory and index state On master: first stash
  11.  
  12. $ echo 2222 > file2
  13.  
  14. $ git stash save "second stash"
  15. warning: LF will be replaced by CRLF in file2.
  16. The file will have its original line endings in your working directory
  17. Saved working directory and index state On master: second stash
  18.  
  19. $ git stash list
  20. stash@{0}: On master: second stash
  21. stash@{1}: On master: first stash

从上边的结果可以看出，最近的储藏编号为0，然后依次编号。

git stash show命令则可以显示给定储藏条目相对于它的父提交的索引和文件变更记录：

  1. $ git stash show
  2.  file2 | 2 +-
  3.  1 file changed, 1 insertion(+), 1 deletion(-)

上边的结果显示了最近一次储藏内容的文件变更记录，+表示新增了一行，-表示删除了一行，这也就是file2的修改变更。

但是上边打印的内容好像作用不大，此时可以使用-p参数：

  1. $ git stash show -p
  2. diff --git a/file2 b/file2
  3. index acbe86c..c7dc989 100644
  4. --- a/file2
  5. +++ b/file2
  6. @@ -1 +1 @@
  7. -abcd
  8. +2222

上边的打印结果就明确多了，该命令默认打印都是最近的储藏，不过也可以指定打印特定储藏的内容。

而基于git stash的命令特征，比如save后工作目录和索引是干净的，可以应用如下场景：

  • 如果某文件当前已经修改，而远程版本库中已发生更新，此时需要拉取该文件以便获取该文件的最新内容，而在拉取操作前需要先储藏，不然可能会丢失已有的修改
  • 如果某个修改虽然尚未结束，但已明确该修改不需要了，便可以先save，再drop以获得干净的工作目录和索引

该命令使用的重点就是要明确该命令前后对于工作目录和索引的影响。

此外还有一种情况，若在恢复储藏后，需要执行冲突解决，而该冲突解决太麻烦时，则可以使用git stash branch基于储藏内容生成时的提交将储藏内容转换到一个新分支：

  1. $ echo 1111 > file1
  2.  
  3. $ git status
  4. On branch master
  5. Changes not staged for commit:
  6.   (use "git add <file>..." to update what will be committed)
  7.   (use "git restore <file>..." to discard changes in working directory)
  8.         modified:   file1
  9.  
  10. no changes added to commit (use "git add" and/or "git commit -a")
  11.  
  12. $ git stash save
  13. warning: LF will be replaced by CRLF in file1.
  14. The file will have its original line endings in your working directory
  15. Saved working directory and index state WIP on master: 450aae2 commit file3
  16.  
  17. $ echo 4444 > file4
  18.  
  19. $ git add file4
  20. warning: LF will be replaced by CRLF in file4.
  21. The file will have its original line endings in your working directory
  22.  
  23. $ git commit -m "commit file4"
  24. [master 54cf89a] commit file4
  25.  1 file changed, 1 insertion(+)
  26.  create mode 100644 file4
  27.  
  28. $ git stash branch other
  29. Switched to a new branch 'other'
  30. On branch other
  31. Changes not staged for commit:
  32.   (use "git add <file>..." to update what will be committed)
  33.   (use "git restore <file>..." to discard changes in working directory)
  34.         modified:   file1
  35.  
  36. no changes added to commit (use "git add" and/or "git commit -a")
  37. Dropped refs/stash@{0} (ee5e2035584842a880d41d3d97e41edbe5742a85)
  38.  
  39. $ git branch
  40.   master
  41. * other
  42.  
  43. $ git status
  44. On branch other
  45. Changes not staged for commit:
  46.   (use "git add <file>..." to update what will be committed)
  47.   (use "git restore <file>..." to discard changes in working directory)
  48.         modified:   file1
  49.  
  50. no changes added to commit (use "git add" and/or "git commit -a")
  51.  
  52. $ ls
  53. file1  file2  file3

此时确实会将捕获的储藏转换为一个分支，转换到分支并不意味着在出现冲突时可以避免，只是有了一个更稳定的起点进行冲突处理，这种情况应用于较为复杂的场景中，否则便可以直接使用分支和提交机制了。

引用日志

引用日志(reflog)记录非裸版本库中分支头的改变，每次对引用的更新，包括对HEAD的，应用日志都会更新以记录这些应用发生了哪些变化，同样，也可以通过引用日志来进行分支操作的回溯。

更新引用日志的基本操作包括：

  • 复制
  • 推送
  • 提交
  • 修改或创建分支
  • 变基操作
  • 重置操作

从上面内容来看，任何修改引用或变更分支头的Git操作都会记录。

默认情况下，引用日志在非裸版本库中是启用的，在裸版本库中是禁用的。该设置是由配置选项core.logAllRefUpdates控制的。

可以看一下引用日志：

  1. $ git reflog show
  2. 450aae2 (HEAD -> other) HEAD@{0}: checkout: moving from master to other
  3. 54cf89a (master) HEAD@{1}: commit: commit file4
  4. 450aae2 (HEAD -> other) HEAD@{2}: reset: moving to HEAD
  5. 450aae2 (HEAD -> other) HEAD@{3}: reset: moving to HEAD
  6. 450aae2 (HEAD -> other) HEAD@{4}: reset: moving to HEAD
  7. 450aae2 (HEAD -> other) HEAD@{5}: reset: moving to HEAD
  8. 450aae2 (HEAD -> other) HEAD@{6}: reset: moving to HEAD
  9. 450aae2 (HEAD -> other) HEAD@{7}: reset: moving to HEAD
  10. 450aae2 (HEAD -> other) HEAD@{8}: reset: moving to HEAD
  11. 450aae2 (HEAD -> other) HEAD@{9}: reset: moving to HEAD
  12. 450aae2 (HEAD -> other) HEAD@{10}: reset: moving to HEAD
  13. 450aae2 (HEAD -> other) HEAD@{11}: reset: moving to HEAD
  14. 450aae2 (HEAD -> other) HEAD@{12}: commit: commit file3
  15. b17a9b7 HEAD@{13}: reset: moving to HEAD
  16. b17a9b7 HEAD@{14}: commit: commit file2
  17. 39727b4 HEAD@{15}: commit (initial): commit file1

 引用日志记录所有引用的事务处理，但是git reflog show命令一次只显示一个引用的事务，上面的引用日志显示的就是HEAD。而也可以打印其它引用名，比如分支：

  1. $ git reflog other
  2. 450aae2 (HEAD -> other) other@{0}: branch: Created from 450aae23b5b1bcc0cb014f552fc1d8e223b43162

引用日志的每一行都记录了引用历史记录中的单次事务，从最近的变更开始倒序显示。从左到右的打印分别是变更提交ID，顺序排列的别名，事务描述。

既然打印了上面的内容，那么就可以通过Git命令来查看该事务的内容：

  1. $ git show HEAD@{1}
  2. commit 54cf89a81437e5b8769b46cd9819cb6e85fc0731 (master)
  3. Author: wood_glb <wood_glb@git.com>
  4. Date:   Sun Jul 3 22:38:15 2022 +0800
  5.  
  6.     commit file4
  7.  
  8. diff --git a/file4 b/file4
  9. new file mode 100644
  10. index 0000000..b0f6d94
  11. --- /dev/null
  12. +++ b/file4
  13. @@ -0,0 +1 @@
  14. +4444

这也就是说，不管是什么事务或者变更，只要是涉及到引用日志中的条目，就可以详细查看，已获知引用的具体变更。

但同时引用日志中的打印并不一定具体提交上的父子关系，因为引用日志记录的只是引用的变更历史，是git reflog，而不是git log。

同时Git还支持多类英语的限定符在花括号中作为引用的一部分，这可能有点像字符串匹配的模糊查询：

  1. $ git log 'HEAD@{last sunday}'
  2. commit 450aae23b5b1bcc0cb014f552fc1d8e223b43162 (HEAD -> other)
  3. Author: wood_glb <wood_glb@git.com>
  4. Date:   Sun Jul 3 21:19:13 2022 +0800
  5.  
  6.     commit file3
  7.  
  8. commit b17a9b72e5bad80fe4da03c191813dded68525d8
  9. Author: wood_glb <wood_glb@git.com>
  10. Date:   Sun Jul 3 21:17:34 2022 +0800
  11.  
  12.     commit file2
  13.  
  14. commit 39727b4522b0273ddfd848cf05faa8f460fb492d
  15. Author: wood_glb <wood_glb@git.com>
  16. Date:   Sun Jul 3 21:17:31 2022 +0800
  17.  
  18.     commit file1

或者：

  1. $ git log '@{last sunday}'
  2. commit 450aae23b5b1bcc0cb014f552fc1d8e223b43162 (HEAD -> other)
  3. Author: wood_glb <wood_glb@git.com>
  4. Date:   Sun Jul 3 21:19:13 2022 +0800
  5.  
  6.     commit file3
  7.  
  8. commit b17a9b72e5bad80fe4da03c191813dded68525d8
  9. Author: wood_glb <wood_glb@git.com>
  10. Date:   Sun Jul 3 21:17:34 2022 +0800
  11.  
  12.     commit file2
  13.  
  14. commit 39727b4522b0273ddfd848cf05faa8f460fb492d
  15. Author: wood_glb <wood_glb@git.com>
  16. Date:   Sun Jul 3 21:17:31 2022 +0800
  17.  
  18.     commit file1

虽然Git针对引用支持大量的日期限定符，但其并不是万能的，这有点像是字符串的规则匹配，当你的字符串符合其内容的匹配规则时，就可以成功解析，换言之，若想要正常使用而不出错，最好还是有一个固定的书写风格。同时从上面的内容也可以看出@前的引用名如果省略，就默认为当前分支的HEAD。

同时Git还会自动执行垃圾回收机制，以保证引用日志不会因为项目的迭代而变得过于巨大，这个过程中，旧的引用日志会被丢弃。通常情况下，一个提交，如果既不能从某个分支或引用指向，也不可达，就默认在30天后国企，而可达的提交默认在90天后过期。

也可以设置配置gc.reflogExpireUnreachable和gc.reflogExpire来设置垃圾回收机制的时间，同时也可以使用git reflog delete来手动删除条目，使用git reflog expire来让条目过期并被立即删除，或者可以使用下述命令来强制使引用日志过期：

  1. $ git reflog expire --expire=now --all
  2.  
  3. $ git gc
  4. Enumerating objects: 12, done.
  5. Counting objects: 100% (12/12), done.
  6. Delta compression using up to 4 threads
  7. Compressing objects: 100% (7/7), done.
  8. Writing objects: 100% (12/12), done.
  9. Total 12 (delta 2), reused 0 (delta 0), pack-reused 0

同时引用日志都储存在.git/logs目录中，.git/logs/HEAD文件包含HEAD值的历史记录，其子目录.git/logs/refs包含所有引用的历史记录，其中也包括储藏，其子目录.git/logs/refs/heads包含分支头的历史记录。

在引用日志中存储的所有信息，特别是.git/logs目录中的一切内容，终归是临时的，不会对整个版本库存在任何影响，因此删除.git/logs目录或关闭引用日志其实是无所谓的，其后果只是不能解析HEAD@{1}这样的形式而已。

相反，引用日志中可能存在不可达的提交，此时启动引用日志会引入指向提交的引用，而这些提交又是不可达的，而如果需要清理版本库，删除引用日志就会移除这些不可达的提交。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小小林熬夜学编程/article/detail/626000
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号