如无特别说明，本人的所有 Git 操作都是在 Github 上面的，主要使用的是 Github-Desktop

git 文档
https://git-scm.com/docs

本地分支删除

查看项目的分支们(包括本地和远程)

1

$ git branch -a  

删除本地分支

1

$ git branch -d <BranchName>

reset 删除错误提交的commit

使用这个的前提条件是没有push,一般不建议push -f
git reset --hard <commit_id> 回退到某一版本。
git reset --hard head~1 回退一个版本(数字2自然就是两个版本啦)
然后 git push --force

rebase 伪造历史

git rebase -i HEAD~10 (修改最近10个历史)

下面是rebase打开的文本里命令的提示(git是通过判断进程创建以及进程是否仍然存在来判断用户是否开始、结束编辑，所以多标签的文本编辑器会影响git判断你是否还在编辑)

1
2
3
4
5
6
7
8
9
10

# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]

其中每个历史里的变动占一行，我们只要改前面的pick即可，其中主用的一般是squash，squash会合并改动，再次rebase时是不会拆分的。edit则是修订历史变动里的错误。也可以改动这些变动的顺序。

需要注意的是git里以记录改动为主，如果修改历史变动是会改变现有代码的(特别是你把某个文件的最后一次commit给弄没的时候)。drop 意味着当时进行的修改也会被取消。很容易造成冲突(conflict)，
所以一般是建议squash来合并commit

最后 git push --force
这个命令会把远程的彻底抹掉，出问题也会很彻底的，所以要谨慎。

conflict处理

eol & ignoreCase

eol 问题见 Git eol

大小写问题见 https://github.com/Candinya/Kratos-Rebirth/issues/208

1

git config core.ignorecase false

不建议使用 -g

配置保存在git/config

git config

git 配置有 全局配置，参考 proxy

1

git config -g

修改，位于用户文件夹下的.gitconfig

项目个人设置

位于每个项目的.git\config

项目路径下

1

git config 

修改

还有.gitattributes

这种属于每个项目的预定义配置，通常用于统一项目行为，例如https://github.com/pt-plugins/PT-Plugin-Plus/issues/1981

情景使用

本地获取所有远程分支

1
2

git branch -r | grep -v '\->' | sed "s,\x1B\[[0-9;]*[a-zA-Z],,g" | while read remote; do git branch --track "${remote#origin/}" "$remote"; done
git push --all

还原本地分支所有修改

1
2
3
4
5
6

git checkout your-branch-name
git fetch origin
git reset --hard origin/your-branch-name
# -f 是强制执行 (force)
# -d 是同时删除未跟踪的目录 (directory)
git clean -fd

跨平台

eol

之前被坑过一次，py 文件上传到 Github 后下回来全部用不了，最后发现是因为换行符的问题。（这个现在想来可能是二进制文件没正常识别导致的，实际解决问题的可能是text=auto）
默认上传都是自动改成 Linux(LF) 上传，下下来就还是 LF，Win 上面就全炸了。

默认行为core.autocrlf=input 目前查看(git config --list)是 core.autocrlf=true。但有文章说默认是false，该环境应该是Linux，可能 Github-desktop 的有所不同，如果 Windows 先装 git 可能也不一样。（PS，还有个 Microsoft.Git）

行为说明

1
2
3

false 对换行符不做任何修改
True  上传为 lf，git 检出自动替换为 crlf，需要提醒，不确定检出时替换会不会因为文件后缀问题失效，因为部分文件可能不会被识别为 text
input 上传为 lf，检出不做改动，可以避免将 crlf 提交到数据库

一般这种不建议改全局设置，除非你的全部项目都是只有自己一个人维护，实际上我个人是全局关 autocrlf

团队最好统一配置。可以在项目的 .gitattributes 里改。

一般也不会设置 autocrlf 的值，而是直接固定项目文件的换行符

目前我是自己设了 autocrlf=false，因为我实在受不了预判和"帮你做决定"

text=auto意味着会自动判断，例如一些图片不会被设置文本属性。(之前未设置的时候有遇到exe被设置了text属性)

1
2

* text=auto
* eol=crlf

更具体的还有

1
2
3
4
5

*           text=auto
*.txt		text
*.vcproj	text eol=crlf
*.sh		text eol=lf
*.jpg		-text

-text意味着去除文本属性

顺便给 Hexo 里弄了下，这样每次跑不会一大堆 warning，不过设的是 lf

参考

• https://stackoverflow.com/questions/42667996/enforce-core-autocrlf-input-through-gitattributes
• https://git-scm.com/docs/gitattributes

文件权限问题

1

git config core.filemode false

etc

相关信息 git 代理

注意事项

2025-12-04

git commit hash 是基于文件内容、提交信息、时间戳以及父提交的 Hash 共同计算得出的一个 SHA-1 校验和。

下面主要都是由于时间戳的变化

cherry-pick 虽然修改内容是一样的，但会导致 commit id 变动，从而导致 conflict, 个人建议是除非来源分支以后不准备再使用，否则不要使用 cherry-pick

rebase也是同样

增加 push all -2025-01-15