Workflow on Commentary of Takao

从 git checkout 迁移到 git switch 和恢复

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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