git

快照

git init 初始化仓库, 建立.git

【原理解析】让你完全搞明白Git是如何管理你的代码的】
git:快照,相同的留链接 :分布式版本管理<->集中:增量式
工作区$\xrightarrow{add}$暂存区$\xrightarrow{commit}$代码仓库

.git一种扁平结构:内容与结构分开储存, 思路与我的obsidian类似

blob,标题:哈希值,内容:代码内容, 避免内容重复的文件占用空间
tree,类似目录记录文件结构, 包含标题哈希值对应的文件标题
commit, 记录版本提交信息, 包含tree、作者、前一次提交

git add生成blob,更新暂存区tree
git commit生成快照(commit文件) -a先add，相当于先执行git add -u（-u=–update更新已跟踪文件）
untracked$\xrightarrow{add~~.}$tracked(已跟踪)$\xrightarrow{修改}$unstaged$\xrightarrow{add~~-u}$staged(已暂存) to be committed

git status检查当前状态
git log 历史提交

分支

git branch列出所有本地分支（当前分支前带 *）-r远程 -a所有
git branch <new-branch>创建本地分支
git branch -d <branch>删除本地分支
git branch -m <old branch默认当前> <new branch>更改分支名称

git switch/checkout <branch>切换分支 , 推荐用switch
git checkout <commit-hash/branch>切换到指定提交/分支 .上次提交, 切换到提交进入分离头指针（Detached HEAD)-回到之前状态
git switch -c(-c=–create) 或 git checkout -b <new-branch> <commit-hash,默认当前>创建并切换到新分支
哈希值至少前4位

git merge <branch>将指定分支合并到当前分支

fast-forward(无冲突)直接用原来的commit object
no-fast-forward: use “git merge –abort” to abort the merge;再commit后生成新的commit object
Rebase

commit 规范

1	`<type>(<scope>): <subject>`

type(必须)
用于说明git commit的类别，只允许使用下面的标识。
feat：新功能（feature）。
fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。

fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
docs：文档（documentation）。
style：格式（不影响代码运行的变动）。
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
perf：优化相关，比如提升性能、体验。
test：增加测试。
chore：构建过程或辅助工具的变动。
revert：回滚到上一个版本。
merge：代码合并。
sync：同步主线或分支的Bug。
scope(可选)
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject(必须)
subject是commit目的的简短描述，不超过50个字符。

远程

git remote add [remote] [url]
git pull/fetch/push [remote] [branch]
git pull=git fetch + git merge
git fetch：将远程仓库拉取到本地仓库, 在.git/refs/remotes/<remote-name>/
git diff main origin/main比较区别
git push -u origin main（ -u = –set-upstream设置上游分支）

pull request

Fork（派生）：个人先把主仓库 fork（一份拷贝）到自己账户。
Clone 到本地新建分支进行开发（做功能、修 bug 等）。
Commit 和 Push 代码到自己 fork 的仓库的新分支上。
在 GitHub 上发起 Pull Request，请求将自己提交的更改合并到主仓库（Upstream）的某个分支。
维护者审核、讨论，无误后合并。

.gitignore

# 注释

regex，`**`：跨目录匹配任意字符。

以 / 结尾表示忽略目录（而非同名文件），不以 / 结尾会同时匹配文件和目录, Git 忽略目录时，其下的所有内容（文件和子目录）都将被忽略。
默认表示匹配所有位置的文件, 以 / 开头表示从项目根目录开始匹配，默认从 .gitignore 所在目录的相对路径开始匹配。

使用 ! 前缀强制包含某个文件或目录，从根目录开始匹配，和顺序有关
!dir/ 只允许该目录本身（作为目录结构）被追踪，不自动解封该目录下的文件

*
!iCloudDrive/
!iCloudDrive/iCloud~md~obsidian/
!iCloudDrive/iCloud~md~obsidian/Note/
!iCloudDrive/iCloud~md~obsidian/Note/**/
!iCloudDrive/iCloud~md~obsidian/Note/**/*.md

.gitignore 仅对未跟踪的文件生效。若文件已被 Git 跟踪，需先删除其缓存

LFS(Large File Storage)

将大文件外部储存, 仓库内仅留链接

需要额外下载:git install git-lfs

初始化仓库时:

git lfs install
git lfs track "*.bin"
git lfs track "*.zip"
git lfs track "*.pptx"

lfs track 会修改.gitattributes

隐私

git push会提交所有历史
确保commit时不要包含密码

LF&CRLF

git 的 Windows 客户端基本都会默认设置 core.autocrlf=true，设置core.autocrlf=true, 只要保持工作区都是纯 CRLF 文件，编辑器用 CRLF 换行，就不会出现警告了；
Linux 最好不要设置 core.autocrlf，因为这个配置算是为 Windows 平台定制；
Windows 上设置 core.autocrlf=false，仓库里也没有配置 .gitattributes，很容易引入 CRLF 或者混合换行符（Mixed Line Endings，一个文件里既有 LF 又有CRLF）到版本库，这样就可能产生各种奇怪的问题。

情况一：

Git 可以在你提交时自动地把回车（CR）和换行（LF）转换成换行（LF），而在检出代码时把换行（LF）转换成回车（CR）和换行（LF）。 你可以用 git config --global core.autocrlf true 来打开此项功能。 如果是在 Windows 系统上，把它设置成 true，这样在检出代码时，换行会被转换成回车和换行：

#提交时转换为LF，检出时转换为CRLF
$ git config --global core.autocrlf true
情况二：

如果使用以换行（LF）作为行结束符的 Linux 或 Mac，你不需要 Git 在检出文件时进行自动的转换。然而当一个以回车（CR）和换行（LF）作为行结束符的文件不小心被引入时，你肯定想让 Git 修正。 所以，你可以把 core.autocrlf 设置成 input 来告诉 Git 在提交时把回车和换行转换成换行，检出时不转换：（这样在 Windows 上的检出文件中会保留回车和换行，而在 Mac 和 Linux 上，以及版本库中会保留换行。）

#提交时转换为LF，检出时不转换
$ git config --global core.autocrlf input
情况三：

如果你是 Windows 程序员，且正在开发仅运行在 Windows 上的项目，可以设置 false 取消此功能，把回车保留在版本库中：

#提交检出均不转换
$ git config --global core.autocrlf false
你也可以在文件提交时进行safecrlf检查

#拒绝提交包含混合换行符的文件
git config --global core.safecrlf true   
 
#允许提交包含混合换行符的文件
git config --global core.safecrlf false   
 
#提交包含混合换行符的文件时给出警告
git config --global core.safecrlf warn

云储存

[[Obsidian]]库的git仓库在用户文件夹中, 避免与[[iCloud]]冲突

git

http://kaelvio.com/git/

作者

采薇

发布于

2025年8月5日

许可协议

Robust_Prover 上一篇

强化学习下一篇