<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Git on Commentary of Takao</title><link>https://takao.blog/zh/tags/git/</link><description>Recent content in Git on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>zh</language><copyright>Commentary of Takao</copyright><lastBuildDate>Wed, 15 Jul 2026 22:01:08 +0900</lastBuildDate><atom:link href="https://takao.blog/zh/tags/git/index.xml" rel="self" type="application/rss+xml"/><item><title>通过自定义 Git 配置别名使开发速度加倍</title><link>https://takao.blog/zh/web/git-alias-setup-productivity/</link><pubDate>Sat, 20 Jun 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-alias-setup-productivity/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-alias-setup-productivity-zh.png" alt="Featured image of post 通过自定义 Git 配置别名使开发速度加倍" /&gt;&lt;p&gt;您每天在终端中输入多少次诸如 &lt;code&gt;git status&lt;/code&gt;、&lt;code&gt;git checkout&lt;/code&gt; 或 &lt;code&gt;git commit&lt;/code&gt; 之类的命令？对于活跃的开发人员来说，答案很容易是数十或数百。重复输入这些完整命令会浪费击键次数、增加打字错误并减慢您的开发动力。&lt;/p&gt;</description></item><item><title>使用 SSH 密钥代替 GPG 密钥进行 Git 提交签名</title><link>https://takao.blog/zh/web/git-signing-commits-ssh-keys/</link><pubDate>Mon, 25 May 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-signing-commits-ssh-keys/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-signing-commits-ssh-keys-zh.png" alt="Featured image of post 使用 SSH 密钥代替 GPG 密钥进行 Git 提交签名" /&gt;&lt;p&gt;长期以来，GPG（GNU Privacy Guard）密钥是签署 Git 提交以证明身份并防止篡改的行业标准。然而，设置 GPG 涉及生成密钥环、管理过期日期和调试后台代理，这给开发人员带来了很大的麻烦。&lt;/p&gt;</description></item><item><title>使用 git reflog 恢复已删除的分支和提交</title><link>https://takao.blog/zh/web/git-recovery-deleted-branch-reflog/</link><pubDate>Sat, 25 Apr 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-recovery-deleted-branch-reflog/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-recovery-deleted-branch-reflog-zh.png" alt="Featured image of post 使用 git reflog 恢复已删除的分支和提交" /&gt;&lt;p&gt;“我不小心使用 &lt;code&gt;git branch -D&lt;/code&gt; 删除了本地分支”，或者“我运行了 &lt;code&gt;git reset --hard HEAD~1&lt;/code&gt; 并丢失了我未推送的提交！”如果您使用 Git 工作过一段时间，您可能经历过这些令人胃口大开的时刻之一。&lt;/p&gt;</description></item><item><title>从 git checkout 迁移到 git switch 和恢复</title><link>https://takao.blog/zh/web/git-checkout-restore-switch-commands/</link><pubDate>Wed, 25 Mar 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-checkout-restore-switch-commands/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-checkout-restore-switch-commands-zh.png" alt="Featured image of post 从 git checkout 迁移到 git switch 和恢复" /&gt;&lt;p&gt;开发人员在开始使用 Git 时首先学习的命令之一是 &lt;code&gt;git checkout&lt;/code&gt;。然而，&lt;code&gt;git checkout&lt;/code&gt; 是一个众所周知的重载命令。它处理太多的责任，这使得它成为初学者和经验丰富的开发人员造成混乱和意外文件丢失的常见原因。&lt;/p&gt;</description></item><item><title>Git Merge 与 Git Rebase：操作指南</title><link>https://takao.blog/zh/web/git-merge-vs-rebase-best-practice/</link><pubDate>Wed, 25 Feb 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-merge-vs-rebase-best-practice/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-merge-vs-rebase-best-practice-zh.png" alt="Featured image of post Git Merge 与 Git Rebase：操作指南" /&gt;&lt;p&gt;在 Git 中将一个分支的更改集成到另一个分支时，开发人员通常依赖两个主要命令：&lt;code&gt;git merge&lt;/code&gt; 和 &lt;code&gt;git rebase&lt;/code&gt;。虽然两者都有相同的最终目的——将两个分支的代码整合在一起——但它们解决问题的方式不同，导致提交历史记录截然不同。&lt;/p&gt;</description></item><item><title>自动发布工作流程的常规提交</title><link>https://takao.blog/zh/web/git-semantic-commit-messages-standard/</link><pubDate>Sun, 25 Jan 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-semantic-commit-messages-standard/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-semantic-commit-messages-standard-zh.png" alt="Featured image of post 自动发布工作流程的常规提交" /&gt;&lt;p&gt;在协作软件开发团队中，提交消息结构的不一致会使跟踪更改变得困难。诸如 &lt;code&gt;fix bug&lt;/code&gt;、&lt;code&gt;update code&lt;/code&gt; 或 &lt;code&gt;minor changes&lt;/code&gt; 之类的模糊提交消息会使代码审核和延迟发布文档变得复杂。&lt;/p&gt;</description></item><item><title>使用 git fetch --prune 清理孤立远程分支</title><link>https://takao.blog/zh/web/git-prune-clean-remote-branches/</link><pubDate>Thu, 25 Dec 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-prune-clean-remote-branches/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-prune-clean-remote-branches-zh.png" alt="Featured image of post 使用 git fetch --prune 清理孤立远程分支" /&gt;&lt;p&gt;在使用 GitHub 或 GitLab 的现代开发工作流程中，一旦合并了相应的拉取请求 (PR)，功能分支通常就会在远程主机上删除。&lt;/p&gt;
&lt;p&gt;但是，当您在本地终端中运行 &lt;code&gt;git branch -a&lt;/code&gt; 时，您会注意到 &lt;strong&gt;指向那些已删除的远程分支（例如 &lt;code&gt;remotes/origin/feature-xxx&lt;/code&gt;）的引用无限期地保留在您的分支列表中。&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>使用 git revert -m 安全地撤消合并提交</title><link>https://takao.blog/zh/web/git-revert-merge-commit-safe/</link><pubDate>Tue, 25 Nov 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-revert-merge-commit-safe/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-revert-merge-commit-safe-zh.png" alt="Featured image of post 使用 git revert -m 安全地撤消合并提交" /&gt;&lt;p&gt;将功能分支合并到主发布分支 (&lt;code&gt;main&lt;/code&gt;) 后，您可能会发现一个严重的错误，需要您立即回滚集成。&lt;/p&gt;
&lt;p&gt;通过标准提交，您可以使用 &lt;code&gt;git revert &amp;lt;commit-hash&amp;gt;&lt;/code&gt; 轻松撤消更改。但是，尝试恢复合并提交会直接导致 Git 错误：&lt;code&gt;fatal: commit &amp;lt;hash&amp;gt; is a merge but no -m option was given.&lt;/code&gt;&lt;/p&gt;</description></item><item><title>使用 git bisect 快速查找回归提交</title><link>https://takao.blog/zh/web/git-bisect-debug-regression/</link><pubDate>Mon, 20 Oct 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-bisect-debug-regression/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-bisect-debug-regression-zh.png" alt="Featured image of post 使用 git bisect 快速查找回归提交" /&gt;&lt;p&gt;“昨天还能用，今天就坏了。”在任何活跃的软件项目中，回归错误都必然会出现。从数百或数千个提交中查找引入错误的确切提交就像大海捞针一样。&lt;/p&gt;
&lt;p&gt;您可以使用 Git 的内置调试工具：&lt;strong&gt;&lt;code&gt;git bisect&lt;/code&gt;&lt;/strong&gt;，而不是手动一一检查提交或花费数小时分析代码更改。&lt;/p&gt;</description></item><item><title>使用 GPG 或 SSH 和验证徽章签署 Git 提交</title><link>https://takao.blog/zh/web/git-commit-signing-gpg/</link><pubDate>Thu, 25 Sep 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-commit-signing-gpg/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-commit-signing-gpg-zh.png" alt="Featured image of post 使用 GPG 或 SSH 和验证徽章签署 Git 提交" /&gt;&lt;p&gt;在 GitHub 上查看提交日志时，您可能会注意到某些提交旁边有一个绿色的“&lt;strong&gt;已验证&lt;/strong&gt;”徽章。此标签表明提交已经过加密签名并确认来自合法的、经过验证的用户。&lt;/p&gt;
&lt;p&gt;默认情况下，Git 允许开发人员使用 &lt;code&gt;git config user.email&lt;/code&gt; 等简单命令配置他们选择的任何名称和电子邮件地址。这意味着冒充是微不足道的。为了保证身份验证并防止未经授权的贡献，强烈建议&lt;strong&gt;提交签名&lt;/strong&gt;。&lt;/p&gt;</description></item><item><title>高级 git stash：保存未跟踪的内容并部分恢复</title><link>https://takao.blog/zh/web/git-stash-advanced-techniques/</link><pubDate>Wed, 20 Aug 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-stash-advanced-techniques/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-stash-advanced-techniques-zh.png" alt="Featured image of post 高级 git stash：保存未跟踪的内容并部分恢复" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;在团队开发中，在为功能分支编写代码的过程中，您经常需要切换分支来解决紧急的错误修复。&lt;/p&gt;
&lt;p&gt;虽然您可以将半成品作为临时“WIP”提交提交，但更简洁的方法是使用 &lt;strong&gt;&lt;code&gt;git stash&lt;/code&gt;&lt;/strong&gt;。&lt;/p&gt;</description></item><item><title>使用 .git-blame-ignore-revs 忽略 gitblame 中的格式提交</title><link>https://takao.blog/zh/web/git-blame-ignore-revs/</link><pubDate>Sun, 20 Jul 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-blame-ignore-revs/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-blame-ignore-revs-zh.png" alt="Featured image of post 使用 .git-blame-ignore-revs 忽略 gitblame 中的格式提交" /&gt;&lt;p&gt;当审核代码库以找出何时以及为何引入一行代码时，&lt;code&gt;git blame&lt;/code&gt; 是开发人员最好的朋友。然而，大型样式更新、代码格式化程序采用（如 Prettier）或全局 linter 自动修复可能会扰乱这段历史。单个批量重新格式化提交可以重写整个存储库的代码作者身份标签，隐藏原始开发人员和引入实际业务逻辑的提交。&lt;/p&gt;</description></item><item><title>使用 git worktree 进行并发分支开发</title><link>https://takao.blog/zh/web/git-worktree-multi-branches/</link><pubDate>Tue, 20 May 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-worktree-multi-branches/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-worktree-multi-branches-zh.png" alt="Featured image of post 使用 git worktree 进行并发分支开发" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;在日常软件开发中，在为功能分支编写代码时经常会被紧急修复请求打断。&lt;/p&gt;
&lt;p&gt;传统上，开发人员通过以下两种方式之一处理此问题：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;使用 &lt;code&gt;git stash&lt;/code&gt; 暂时搁置活动更改，切换分支以修复错误，提交，切换回来，然后运行 ​​&lt;code&gt;git stash pop&lt;/code&gt;。&lt;/li&gt;
&lt;li&gt;将存储库的完全独立的副本克隆到另一个目录中以处理修补程序。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;但是，存储在恢复时存在冲突错误的风险，并且克隆同一存储库的多个副本会浪费磁盘空间并使本地提交同步变得复杂。&lt;/p&gt;</description></item><item><title>使用 Husky 和 ​​Git Hooks 自动进行预提交检查</title><link>https://takao.blog/zh/web/git-hooks-husky-prevent-bugs/</link><pubDate>Sun, 20 Apr 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-hooks-husky-prevent-bugs/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-hooks-husky-prevent-bugs-zh.png" alt="Featured image of post 使用 Husky 和 ​​Git Hooks 自动进行预提交检查" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;在团队开发中，提交具有语法错误或格式错误的代码等简单错误很常见。这些问题可能会破坏 CI 构建或在代码审查期间导致混乱的格式冲突。&lt;/p&gt;
&lt;p&gt;您可以自动执行这些检查，而不是依赖开发人员的警惕性来执行准则。&lt;/p&gt;</description></item><item><title>gitcherry-pick 用于特定提交的安全用例</title><link>https://takao.blog/zh/web/git-cherry-pick-usecases/</link><pubDate>Tue, 25 Mar 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-cherry-pick-usecases/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-cherry-pick-usecases-zh.png" alt="Featured image of post gitcherry-pick 用于特定提交的安全用例" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;在团队开发中，您经常会遇到需要立即将特定错误修复从正在进行的功能分支部署到生产分支（&lt;code&gt;main&lt;/code&gt;）的情况，而不释放半完成的功能本身。&lt;/p&gt;
&lt;p&gt;合并整个分支会引入未完成的代码。&lt;/p&gt;</description></item><item><title>使用交互式 Git Rebase 清理提交历史记录</title><link>https://takao.blog/zh/web/git-rebase-interactive-flow/</link><pubDate>Thu, 20 Feb 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-rebase-interactive-flow/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-rebase-interactive-flow-zh.png" alt="Featured image of post 使用交互式 Git Rebase 清理提交历史记录" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;在日常软件开发过程中，通常会出现混乱的提交历史记录，其中充满了“WIP”、“修复拼写错误”或“测试部署”等日志。&lt;/p&gt;
&lt;p&gt;如果将这些提交直接合并到主分支中，则查找引入特定错误的位置或理解添加一行代码的原因变得极其困难。&lt;/p&gt;</description></item><item><title>用于自动化的 Git Hooks：超越代码质量</title><link>https://takao.blog/zh/web/git-hooks-automation/</link><pubDate>Tue, 24 Dec 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-hooks-automation/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-hooks-automation-zh.png" alt="Featured image of post 用于自动化的 Git Hooks：超越代码质量" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;Git 挂钩是在 Git 生命周期中的特定点自动运行的可执行脚本。虽然许多开发人员仅将它们与代码格式化和 linting 联系起来，但它们的潜力远远超出了工作流程自动化、项目管理和团队协作。本文探讨了如何利用 Git hook 来实现全面的自动化策略。&lt;/p&gt;</description></item><item><title>Git LFS：管理存储库中的大文件</title><link>https://takao.blog/zh/web/git-lfs/</link><pubDate>Tue, 26 Nov 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-lfs/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-lfs-zh.png" alt="Featured image of post Git LFS：管理存储库中的大文件" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;Git 是为文本文件而不是大型二进制文件设计的。当大文件进入 Git 存储库时，克隆时间会增加，存储库大小会膨胀，并且 &lt;code&gt;git log&lt;/code&gt; 等操作会变慢。 Git LFS（大文件存储）通过用存储库中的文本指针文件替换大文件，同时将实际内容存储在远程服务器上来解决这个问题。&lt;/p&gt;</description></item><item><title>Git Squash Merge：团队的清理历史策略</title><link>https://takao.blog/zh/web/git-squash-merge/</link><pubDate>Tue, 21 May 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-squash-merge/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-squash-merge-zh.png" alt="Featured image of post Git Squash Merge：团队的清理历史策略" /&gt;&lt;h2 id="介绍"&gt;介绍
&lt;/h2&gt;&lt;p&gt;Git 历史记录是您的团队和未来的您的沟通工具。干净、可读的历史记录使调试、代码审查和发布管理变得更加容易。挤压合并是维护干净历史的主要策略之一，但了解何时以及如何使用它以及何时选择替代方案需要了解所涉及的权衡。本文提供了团队压缩合并策略的综合指南。&lt;/p&gt;</description></item><item><title>Git 子模块：有效管理嵌套存储库</title><link>https://takao.blog/zh/web/git-submodules/</link><pubDate>Mon, 22 Jan 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/git-submodules/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-submodules-zh.png" alt="Featured image of post Git 子模块：有效管理嵌套存储库" /&gt;&lt;p&gt;Git 子模块允许您将一个 Git 存储库嵌套在另一个 Git 存储库中，同时为每个存储库维护独立的版本控制。它们对于管理共享库、第三方依赖项或需要精确提交级别控制的配置集合非常有用。然而，子模块具有复杂性，需要了解其底层机制。&lt;/p&gt;</description></item><item><title>Git 教程：从基础知识到高级工作流程</title><link>https://takao.blog/zh/web/how-to-git/</link><pubDate>Sun, 10 Sep 2023 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/how-to-git/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/how-to-git-zh.png" alt="Featured image of post Git 教程：从基础知识到高级工作流程" /&gt;&lt;h1 id="git-教程项目管理和版本控制基础知识"&gt;Git 教程：项目管理和版本控制基础知识
&lt;/h1&gt;&lt;p&gt;Git 是现代软件开发中版本控制的事实上的标准。它跟踪代码库的每次更改，实现无缝团队协作，并为实验提供安全网。无论您是维护个人项目的独立开发人员还是大型工程团队的一员，掌握 Git 都是必不可少的。本指南涵盖了 Git 从基本原理到高级工作流程，以及实用命令和真实场景。&lt;/p&gt;</description></item><item><title>GitHub 指南：协作和项目管理</title><link>https://takao.blog/zh/web/how-to-github/</link><pubDate>Sun, 10 Sep 2023 00:00:00 +0900</pubDate><guid>https://takao.blog/zh/web/how-to-github/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/how-to-github-zh.png" alt="Featured image of post GitHub 指南：协作和项目管理" /&gt;&lt;h1 id="github-指南协作和项目管理"&gt;GitHub 指南：协作和项目管理
&lt;/h1&gt;&lt;p&gt;GitHub 已成为软件开发人员和项目经理等的重要平台。它将强大的版本控制与社交编码功能相结合，使团队协作无缝。无论您是为开源项目做出贡献还是管理私人团队存储库，GitHub 都可以提供您跟踪更改、审查代码和自动化工作流程所需的工具。本指南介绍了从帐户设置到高级项目管理的所有内容。&lt;/p&gt;</description></item></channel></rss>