Git on Commentary of Takao

通过自定义 Git 配置别名使开发速度加倍

Sat, 20 Jun 2026 00:00:00 +0900

您每天在终端中输入多少次诸如 git status、git checkout 或 git commit 之类的命令？对于活跃的开发人员来说，答案很容易是数十或数百。重复输入这些完整命令会浪费击键次数、增加打字错误并减慢您的开发动力。

使用 SSH 密钥代替 GPG 密钥进行 Git 提交签名

Mon, 25 May 2026 00:00:00 +0900

长期以来，GPG（GNU Privacy Guard）密钥是签署 Git 提交以证明身份并防止篡改的行业标准。然而，设置 GPG 涉及生成密钥环、管理过期日期和调试后台代理，这给开发人员带来了很大的麻烦。

使用 git reflog 恢复已删除的分支和提交

Sat, 25 Apr 2026 00:00:00 +0900

“我不小心使用 git branch -D 删除了本地分支”，或者“我运行了 git reset --hard HEAD~1 并丢失了我未推送的提交！”如果您使用 Git 工作过一段时间，您可能经历过这些令人胃口大开的时刻之一。

从 git checkout 迁移到 git switch 和恢复

Wed, 25 Mar 2026 00:00:00 +0900

开发人员在开始使用 Git 时首先学习的命令之一是 git checkout。然而，git checkout 是一个众所周知的重载命令。它处理太多的责任，这使得它成为初学者和经验丰富的开发人员造成混乱和意外文件丢失的常见原因。

Git Merge 与 Git Rebase：操作指南

Wed, 25 Feb 2026 00:00:00 +0900

在 Git 中将一个分支的更改集成到另一个分支时，开发人员通常依赖两个主要命令：git merge 和 git rebase。虽然两者都有相同的最终目的——将两个分支的代码整合在一起——但它们解决问题的方式不同，导致提交历史记录截然不同。

自动发布工作流程的常规提交

Sun, 25 Jan 2026 00:00:00 +0900

在协作软件开发团队中，提交消息结构的不一致会使跟踪更改变得困难。诸如 fix bug、update code 或 minor changes 之类的模糊提交消息会使代码审核和延迟发布文档变得复杂。

使用 git fetch --prune 清理孤立远程分支

Thu, 25 Dec 2025 00:00:00 +0900

在使用 GitHub 或 GitLab 的现代开发工作流程中，一旦合并了相应的拉取请求 (PR)，功能分支通常就会在远程主机上删除。

但是，当您在本地终端中运行 git branch -a 时，您会注意到 指向那些已删除的远程分支（例如 remotes/origin/feature-xxx）的引用无限期地保留在您的分支列表中。

使用 git revert -m 安全地撤消合并提交

Tue, 25 Nov 2025 00:00:00 +0900

将功能分支合并到主发布分支 (main) 后，您可能会发现一个严重的错误，需要您立即回滚集成。

通过标准提交，您可以使用 git revert <commit-hash> 轻松撤消更改。但是，尝试恢复合并提交会直接导致 Git 错误：fatal: commit <hash> is a merge but no -m option was given.

使用 git bisect 快速查找回归提交

Mon, 20 Oct 2025 00:00:00 +0900

“昨天还能用，今天就坏了。”在任何活跃的软件项目中，回归错误都必然会出现。从数百或数千个提交中查找引入错误的确切提交就像大海捞针一样。

您可以使用 Git 的内置调试工具：git bisect，而不是手动一一检查提交或花费数小时分析代码更改。

使用 GPG 或 SSH 和验证徽章签署 Git 提交

Thu, 25 Sep 2025 00:00:00 +0900

在 GitHub 上查看提交日志时，您可能会注意到某些提交旁边有一个绿色的“已验证”徽章。此标签表明提交已经过加密签名并确认来自合法的、经过验证的用户。

默认情况下，Git 允许开发人员使用 git config user.email 等简单命令配置他们选择的任何名称和电子邮件地址。这意味着冒充是微不足道的。为了保证身份验证并防止未经授权的贡献，强烈建议提交签名。

高级 git stash：保存未跟踪的内容并部分恢复

Wed, 20 Aug 2025 00:00:00 +0900

介绍

在团队开发中，在为功能分支编写代码的过程中，您经常需要切换分支来解决紧急的错误修复。

虽然您可以将半成品作为临时“WIP”提交提交，但更简洁的方法是使用 git stash。

使用 .git-blame-ignore-revs 忽略 gitblame 中的格式提交

Sun, 20 Jul 2025 00:00:00 +0900

当审核代码库以找出何时以及为何引入一行代码时，git blame 是开发人员最好的朋友。然而，大型样式更新、代码格式化程序采用（如 Prettier）或全局 linter 自动修复可能会扰乱这段历史。单个批量重新格式化提交可以重写整个存储库的代码作者身份标签，隐藏原始开发人员和引入实际业务逻辑的提交。

使用 git worktree 进行并发分支开发

Tue, 20 May 2025 00:00:00 +0900

介绍

在日常软件开发中，在为功能分支编写代码时经常会被紧急修复请求打断。

传统上，开发人员通过以下两种方式之一处理此问题：

使用 git stash 暂时搁置活动更改，切换分支以修复错误，提交，切换回来，然后运行 git stash pop。
将存储库的完全独立的副本克隆到另一个目录中以处理修补程序。

但是，存储在恢复时存在冲突错误的风险，并且克隆同一存储库的多个副本会浪费磁盘空间并使本地提交同步变得复杂。

使用 Husky 和 Git Hooks 自动进行预提交检查

Sun, 20 Apr 2025 00:00:00 +0900

介绍

在团队开发中，提交具有语法错误或格式错误的代码等简单错误很常见。这些问题可能会破坏 CI 构建或在代码审查期间导致混乱的格式冲突。

您可以自动执行这些检查，而不是依赖开发人员的警惕性来执行准则。

gitcherry-pick 用于特定提交的安全用例

Tue, 25 Mar 2025 00:00:00 +0900

介绍

在团队开发中，您经常会遇到需要立即将特定错误修复从正在进行的功能分支部署到生产分支（main）的情况，而不释放半完成的功能本身。

合并整个分支会引入未完成的代码。

使用交互式 Git Rebase 清理提交历史记录

Thu, 20 Feb 2025 00:00:00 +0900

介绍

在日常软件开发过程中，通常会出现混乱的提交历史记录，其中充满了“WIP”、“修复拼写错误”或“测试部署”等日志。

如果将这些提交直接合并到主分支中，则查找引入特定错误的位置或理解添加一行代码的原因变得极其困难。

Git 教程：从基础知识到高级工作流程

Sun, 10 Sep 2023 00:00:00 +0900

Git 教程：项目管理和版本控制基础知识

Git 是现代软件开发中版本控制的事实上的标准。它跟踪代码库的每次更改，实现无缝团队协作，并为实验提供安全网。无论您是维护个人项目的独立开发人员还是大型工程团队的一员，掌握 Git 都是必不可少的。本指南涵盖了 Git 从基本原理到高级工作流程，以及实用命令和真实场景。