Github 优雅系列：GitHub 提交配置与管理

Maker’s Notes

专栏索引专栏目录 / Daily Engineering Notes / 章节页

Publish Date: 2025-10-12

Word Count: 1.1k

一、写在前面的话

在搞定了 WSL 的网络和跨文件系统的 Git 卡顿问题后，基本上本地的开发环境就理顺了。

这篇文章算是我自己的一份备忘录。每次换新电脑、重新配环境，或者开启一个新项目时，我都会照着这份清单把 Git 和 GitHub 的基础设置过一遍。把这些细枝末节的东西标准化之后，能省去后续协作中很多不必要的麻烦。

二、基础跑通：SSH 密钥与免密配置

我不推荐用 HTTPS 的方式拉取代码，配置好 SSH Key 是一劳永逸的做法。

1. 本地生成密钥

推荐使用 ed25519 算法，比传统的 RSA 更短也更安全：

1	ssh-keygen -t ed25519 -C "you@example.com"

生成后，将 ~/.ssh/id_ed25519.pub 里的内容复制，粘贴到 [GitHub -> Settings -> SSH and GPG keys] 中。

2. 建立快捷配置

为了防止多密钥冲突或连接超时，我习惯在 ~/.ssh/config 中显式指定 GitHub 的连接配置：

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  PreferredAuthentications publickey

附：如何避免每次 Push 都要输入密钥密码？

如果你在生成密钥时设置了 Passphrase（密码保护），那每次执行 git push 时终端都会弹提示让你输密码，非常烦人。

我之前一直以为要输登录密码，后来发现是输入生成密钥（这鬼能记住）

解决方案：让 ssh-agent 在终端启动时自动帮你加载密钥。

编辑 ~/.bashrc（或 ~/.zshrc），在末尾加上这两行：

1 2	eval "$(ssh-agent -s)" > /dev/null ssh-add ~/.ssh/id_ed25519 2>/dev/null

执行 source ~/.bashrc 生效后，用下面这条命令验证。如果出现 Hi （你的名字）! You've successfully authenticated... 就大功告成了。

1	ssh -T git@github.com

三、仓库管理与全局设置

日常开发中，有些 Git 默认行为并不太符合我们的直觉，我会做如下全局微调：

1. 基础信息与换行符

git config --global user.name "你的名字"
git config --global user.email "you@example.com"

# 解决 Windows(CRLF) 和 Linux(LF) 跨平台换行符冲突的终极方案
git config --global core.autocrlf input

# 禁用 pull 时默认的 merge 行为，保持提交历史干净
git config --global pull.rebase false

2. 模板化全局忽略文件
很多时候我们会不小心把 .vscode/ 或 .DS_Store 传上去。与其每个项目都在 .gitignore 里写一遍，不如设一个全局忽略：
创建 ~/.config/git/ignore，把常见的系统/IDE文件加进去，然后执行：

1	git config --global core.excludesfile ~/.config/git/ignore

3. 保护默认分支
如果你是仓库管理员，一定要去 GitHub 仓库的 Settings -> Branches 中给 main 分支添加规则：
勾选 Require a pull request before merging 和 Require status checks，防止自己或队友手滑直接把炸弹代码 Push 到主分支。

四、提交规范与分支策略

团队协作的核心就是看懂彼此的意图，规范的分支和提交信息很重要。

1. 分支命名约定

新功能：feature/<module>-<keyword>
修 Bug：fix/<issue>-<keyword>
补文档：docs/<topic>

2. 提交信息模版
我会在用户目录下建一个 .gitmessage 文件，内容如下：

1
2
3

<type>: <subject>

<body>

然后在全局配置中启用它：

1	git config --global commit.template ~/.gitmessage

常用 type 参考：feat (功能)、fix (修复)、docs (文档)、refactor (重构)、chore (杂项构建)。

3. Rebase 与合并
拉取最新代码时，尽量使用 git pull --rebase 保持线性的提交历史；准备合并 PR 前，一定先 git status 看一眼，确认没有杂项文件混入。

五、协作技巧

当项目变大或者开源时，可以用上这几个 GitHub 的进阶功能：

Personal Access Token (PAT)：如果在脚本、CI/CD (Actions) 中需要 HTTPS 推送，千万别用账号密码，去申请一个细粒度的 PAT，限制好它的仓库范围和读写权限。
GitHub CLI (gh)：提 PR 速度极快，在终端敲一行就能搞定：
1
gh pr create --fill --web
Issue 模板：在项目的 .github/ISSUE_TEMPLATE/ 目录下准备 bug-report.yml 等文件，能要求提问者把复现步骤写清楚，提升反馈质量。
Code Owners (代码审查负责人)：通过 .github/CODEOWNERS 指定必须 Review 的人，比如：
1
2
* @linda1729
docs/* @docs-team