git/dvc笔记

git

HEAD

HEAD表示分支的最新提交节点
前一个提交版本：HEAD^ == HEAD~1 == HEAD~
前两个提交版本：HEAD^^ == HEAD~2

可以使用@作为HEAD的别名

<commit_id>

<commit_id>可以是以下格式：

• 哈希值
• <branch_name>/<branch_name>^/<branch_name>~2
• HEAD/HEAD^/HEAD~1/@
• 标签名
• 引用路径<branch_name>@{n}和<branch_name>@{time}

git checkout

• git checkout <commit_id> -- <file_path>：恢复或检出指定文件的内容
• git checkout <commit_id>：检出特定的提交
• git checkout -b <new_branch_name> <commit_id>：基于指定的提交创建一个新分支，并立即切换到这个新分支上

git reset

在执行了git commit后想要撤回最近这次（或多次）提交，则需要使用git commit。

• git reset --soft：工作区和暂存区中的修改内容会保留，提交新的commit前需要将不需要的修改unstage
• git reset/git reset --mixed：工作区中的修改内容会保留，但暂存区不会，需要手动将修改内容重新add到暂存区中
• git reset --hard（很少用到）：工作区和暂存区中的修改内容都会删掉，也就是被撤回commit中的修改全都不需要的情况下才使用

文件跟踪状态

仓库中的文件分为以下状态：

• 未跟踪（Untracked）
• 已跟踪（Tracked）
  • 未修改（Unmodified）
  • 已修改（Modified）
  • 已暂存（Staged）

暂存区（.git/index）记录着所有已跟踪文件各种信息：

• 文件路径：文件在项目中的位置。
• 文件的元数据：如文件的修改时间、权限等。
• 文件内容的哈希值（blob 哈希）：这是文件内容的唯一标识，用于检测文件是否发生变化。

git rebase/git merge

参考讲解视频

使用方法：

1. 哪个分支需要合并其他分支的内容，就先切换到哪个分支上
2. 然后执行git rebase <other_branch> / git merge other_branch
3. 解决冲突后，在当前分支上就拥有了其他分支的所有commit

git rebase/git merge区别：

• git rebase是将当前分支从最近公共祖先节点到HEAD的所有节点拼接到另一的HEAD节点。相当于将当前分支分叉的这一段rebase到另一分支的HEAD（不再以最近公共祖先节点为base，而是以另一分支的HEAD为base，所以叫做rebase）
• git merge是产生一个新提交，里面包含最近祖先节点分别到两个HEAD的所有内容

git merge解决冲突：

1. 执行git merge <other_branch>
2. git会提示Automatic merge failed; fix conflicts and then commit the result.
3. 在vscode的源代码管理页面中，找到合并更改这个列表，里面的文件都是有冲突的。一个一个修改合并更改列表里的文件，解决冲突
4. git add . ，或是只add解决冲突的文件，使得合并更改列表里的文件全转入暂存的更改列表下
5. git commit

git rebase解决冲突：

1. 执行git rebase <other_branch>
2. git会提示error: could not apply …
3. 在vscode的源代码管理页面中，找到合并更改这个列表，里面的文件都是有冲突的。一个一个修改合并更改列表里的文件，解决冲突
4. git add . ，或是只add解决冲突的文件，使得合并更改列表里的文件全转入暂存的更改列表下
5. git rebase --continue

git clone

git clone 会下载远程仓库的所有分支的history，但默认情况下，会默认检出远程仓库的主分支，所以执行git branch后只会看到main分支。可以使用git branch -r或git branch -a来查看未被检出的分支。

如果只想下载某个分支的history，并自动切换到该分支，可以执行git clone -b <branch_name> --single-branch

git ls-files

• git ls-files：列出所有已跟踪的文件
• git ls-files --others：列出所有未跟踪的文件
• git ls-files --ignored：列出所有被.gitignore忽略的文件
• git ls-files --cached：列出暂存区（索引）中的文件
• git ls-files --others --exclude-standard：列出所有未跟踪且不在.gitignore中的文件

git rm

• git rm <file>：把文件从工作区和暂存区同时删除
• git rm --cached <file>：把文件从暂存区中删除，但工作区中文件仍然保留

.gitignore

.gitignore对已跟踪文件没有作用，需要使用git rm来先将文件状态变成未跟踪
.gitignore中以/结尾的只对目录起作用，不以/结尾的同时对文件和目录起作用

git diff

• git diff：比较工作区与暂存区之间的差异（即查看尚未暂存的改动）
• git diff --cached：比较暂存区与最新一次提交（HEAD）的差异
• git diff HEAD：比较工作区与最新一次提交的差异
• git diff <commit1> <commit2>：查看任意两个提交之间的文件内容差异
• git diff <branch1> <branch2>：比较两个分支间的文件差异

首次使用git的必要配置

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
git config --global credential.helper cache

dvc

dvc pull

Tracked files                Commands
---------------- ---------------------------------

remote storage
     +
     |         +------------+
     | - - - - | dvc fetch  | ++
     v         +------------+   +   +----------+
project's cache                  ++ | dvc pull |
     +         +------------+   +   +----------+
     | - - - - |dvc checkout| ++
     |         +------------+
     v
 workspace

dvc install

默认会增加以下hook：

• .git/hooks/post-checkout：dvc checkout
• .git/hooks/pre-commit：dvc status
• .git/hooks/pre-push：dvc push

dvc status

无参数情况下，dvc status比较的是工作区和缓存区的文件差异

dvc diff

无参数情况下，dvc diff比较的是工作区和HEAD的差异

dvc config

cache.type

默认情况下，cache.type为reflink, copy，但由于大部分文件系统中reflink不可用，所以实际上默认使用的是copy模式

core.checksum_jobs

计算文件哈希值(md5)时的线程数，但触发多线程计算哈希值的条件较为苛刻，就算触发了也有GIL，基本等同于顺序哈希每个文件，这个config没啥卵用

core.site_cache_dir

在dvc仓库里执行dvc version/dvc doctor可以查看该仓库的site_cache_dir路径，在linux系统中，默认的路径一般位于/var/tmp/dvc/repo/xxx。
该路径下存在三个子目录：

• index：存放远程索引文件，用于优化dvc push, dvc pull, dvc fetch和dvc status -c操作
• hashes：包含一个SQLite state database，里面存储了所有dvc跟踪文件的md5哈希值和checksum（根据mtime、size和inode计算得到，时间花销很小），利用checksum，可以避免不必要的md5哈希计算。
• links：包含一个SQLite state database，里面存储了dvc所创建的file links的信息。该子目录用于调用dvc checkout时清理工作区。