<?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/en/categories/git/</link><description>Recent content in Git on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sat, 13 Jun 2026 23:11:50 +0900</lastBuildDate><atom:link href="https://takao.blog/en/categories/git/index.xml" rel="self" type="application/rss+xml"/><item><title>Using SSH Keys instead of GPG keys for Git Commit Signatures</title><link>https://takao.blog/en/web/git-signing-commits-ssh-keys/</link><pubDate>Mon, 25 May 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-signing-commits-ssh-keys/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Using SSH Keys instead of GPG keys for Git Commit Signatures" /&gt;&lt;p&gt;For a long time, GPG (GNU Privacy Guard) keys were the industry standard for signing Git commits to prove identity and prevent tampering. However, setting up GPG involves generating keyrings, managing expiration dates, and debugging background agents, which introduces substantial friction for developers.&lt;/p&gt;
&lt;p&gt;To eliminate this complexity, Git version 2.34 introduced the ability to &lt;strong&gt;use your existing SSH keys to sign commits directly&lt;/strong&gt;, bypassing the need for GPG keys.&lt;/p&gt;
&lt;p&gt;In this guide, we will explore how to configure Git to use your SSH keys for signing commits, verify keys locally, and enable trust relationships across development teams.&lt;/p&gt;</description></item><item><title>Recovering Deleted Branches and Commits using git reflog</title><link>https://takao.blog/en/web/git-recovery-deleted-branch-reflog/</link><pubDate>Sat, 25 Apr 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-recovery-deleted-branch-reflog/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Recovering Deleted Branches and Commits using git reflog" /&gt;&lt;p&gt;&amp;ldquo;I accidentally deleted a local branch using &lt;code&gt;git branch -D&lt;/code&gt;,&amp;rdquo; or &amp;ldquo;I ran &lt;code&gt;git reset --hard HEAD~1&lt;/code&gt; and lost my unpushed commits!&amp;rdquo; If you have worked with Git for any length of time, you have likely experienced one of these stomach-dropping moments.&lt;/p&gt;
&lt;p&gt;While standard &lt;code&gt;git log&lt;/code&gt; commands won&amp;rsquo;t display references to deleted branches or detached commits, you don&amp;rsquo;t need to panic. Git has a built-in safety net called &lt;strong&gt;&lt;code&gt;git reflog&lt;/code&gt;&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Migrating from git checkout to git switch and restore</title><link>https://takao.blog/en/web/git-checkout-restore-switch-commands/</link><pubDate>Wed, 25 Mar 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-checkout-restore-switch-commands/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Migrating from git checkout to git switch and restore" /&gt;&lt;p&gt;One of the very first commands developers learn when starting out with Git is &lt;code&gt;git checkout&lt;/code&gt;. However, &lt;code&gt;git checkout&lt;/code&gt; is a notoriously overloaded command. It handles too many responsibilities, making it a common source of confusion and accidental file loss for beginners and experienced developers alike.&lt;/p&gt;
&lt;p&gt;To solve this, Git version 2.23 (released in 2019) introduced two dedicated, task-focused alternatives: &lt;strong&gt;&lt;code&gt;git switch&lt;/code&gt;&lt;/strong&gt; and &lt;strong&gt;&lt;code&gt;git restore&lt;/code&gt;&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;In this post, we&amp;rsquo;ll discuss the design problems surrounding &lt;code&gt;git checkout&lt;/code&gt;, explain the roles of the newer commands, and show you how to transition to using them today.&lt;/p&gt;</description></item><item><title>Git Merge vs Git Rebase: Operational Guidelines</title><link>https://takao.blog/en/web/git-merge-vs-rebase-best-practice/</link><pubDate>Wed, 25 Feb 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-merge-vs-rebase-best-practice/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Git Merge vs Git Rebase: Operational Guidelines" /&gt;&lt;p&gt;When integrating changes from one branch into another in Git, developers generally rely on two primary commands: &lt;code&gt;git merge&lt;/code&gt; and &lt;code&gt;git rebase&lt;/code&gt;. While both serve the same ultimate purpose—bringing code from two branches together—they approach the problem differently, resulting in vastly different commit histories.&lt;/p&gt;
&lt;p&gt;Understanding when and why to use each option is key to keeping your project&amp;rsquo;s repository clean, readable, and easy to debug.&lt;/p&gt;
&lt;p&gt;In this post, we will compare the mechanics, advantages, and drawbacks of &lt;code&gt;git merge&lt;/code&gt; and &lt;code&gt;git rebase&lt;/code&gt;, and outline a set of operational guidelines for teams.&lt;/p&gt;</description></item><item><title>Conventional Commits for Automated Release Workflows</title><link>https://takao.blog/en/web/git-semantic-commit-messages-standard/</link><pubDate>Sun, 25 Jan 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-semantic-commit-messages-standard/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Conventional Commits for Automated Release Workflows" /&gt;&lt;p&gt;In a collaborative software development team, inconsistencies in commit message structures can make tracking changes difficult. Vague commit messages like &lt;code&gt;fix bug&lt;/code&gt;, &lt;code&gt;update code&lt;/code&gt;, or &lt;code&gt;minor changes&lt;/code&gt; complicate code auditing and delay release documentation.&lt;/p&gt;
&lt;p&gt;To resolve this issue and maintain a clean, machine-readable commit history, developers around the world adopt the &lt;strong&gt;Conventional Commits&lt;/strong&gt; specification.&lt;/p&gt;
&lt;p&gt;In this article, we&amp;rsquo;ll explain the structure of Conventional Commits, standard prefix classifications, and how this discipline enables automated release operations.&lt;/p&gt;</description></item><item><title>Cleaning Orphan Remote Branches with git fetch --prune</title><link>https://takao.blog/en/web/git-prune-clean-remote-branches/</link><pubDate>Thu, 25 Dec 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-prune-clean-remote-branches/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Cleaning Orphan Remote Branches with git fetch --prune" /&gt;&lt;p&gt;In modern development workflows using GitHub or GitLab, feature branches are typically deleted on the remote host as soon as their corresponding pull request (PR) is merged.&lt;/p&gt;
&lt;p&gt;However, when you run &lt;code&gt;git branch -a&lt;/code&gt; in your local terminal, you will notice that &lt;strong&gt;the references pointing to those deleted remote branches (e.g., &lt;code&gt;remotes/origin/feature-xxx&lt;/code&gt;) remain in your branch list indefinitely.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;This occurs because Git does not automatically sync deletions from remote configurations to your local cache by default.&lt;/p&gt;</description></item><item><title>Undoing Merge Commits Safely using git revert -m</title><link>https://takao.blog/en/web/git-revert-merge-commit-safe/</link><pubDate>Tue, 25 Nov 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-revert-merge-commit-safe/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Undoing Merge Commits Safely using git revert -m" /&gt;&lt;p&gt;Directly after merging a feature branch into your primary release branch (&lt;code&gt;main&lt;/code&gt;), you might discover a severe bug that requires you to immediately roll back the integration.&lt;/p&gt;
&lt;p&gt;With standard commits, you can easily undo changes using &lt;code&gt;git revert &amp;lt;commit-hash&amp;gt;&lt;/code&gt;. However, attempting to revert a merge commit directly results in a Git error: &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;
&lt;p&gt;In this guide, we&amp;rsquo;ll explain why merge reverts require special handling, walk through using the &lt;code&gt;git revert -m&lt;/code&gt; option, and reveal the hidden trap of re-merging reverted features later.&lt;/p&gt;</description></item><item><title>Finding Regression Commits Quickly using git bisect</title><link>https://takao.blog/en/web/git-bisect-debug-regression/</link><pubDate>Mon, 20 Oct 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-bisect-debug-regression/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Finding Regression Commits Quickly using git bisect" /&gt;&lt;p&gt;&amp;ldquo;It worked yesterday, but it is broken today.&amp;rdquo; In any active software project, regression bugs are bound to slip in. Finding the exact commit that introduced a bug out of hundreds or thousands of commits can feel like searching for a needle in a haystack.&lt;/p&gt;
&lt;p&gt;Instead of manually checking out commits one by one or spending hours analyzing code changes, you can use Git&amp;rsquo;s built-in debugging tool: &lt;strong&gt;&lt;code&gt;git bisect&lt;/code&gt;&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;In this article, we&amp;rsquo;ll explain how to use the binary search algorithm of &lt;code&gt;git bisect&lt;/code&gt; to locate the origin of a bug in minutes.&lt;/p&gt;</description></item><item><title>Signing Git Commits with GPG or SSH and Verified Badges</title><link>https://takao.blog/en/web/git-commit-signing-gpg/</link><pubDate>Thu, 25 Sep 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-commit-signing-gpg/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Signing Git Commits with GPG or SSH and Verified Badges" /&gt;&lt;p&gt;When reviewing commit logs on GitHub, you&amp;rsquo;ve likely noticed a green &amp;ldquo;&lt;strong&gt;Verified&lt;/strong&gt;&amp;rdquo; badge next to some commits. This label indicates that the commit has been cryptographically signed and confirmed to originate from a legitimate, validated user.&lt;/p&gt;
&lt;p&gt;By default, Git allows developers to configure any name and email address they choose using simple commands like &lt;code&gt;git config user.email&lt;/code&gt;. This means impersonation is trivial. To guarantee identity authentication and protect against unauthorized contributions, &lt;strong&gt;commit signing&lt;/strong&gt; is highly recommended.&lt;/p&gt;</description></item><item><title>Advanced git stash: Saving Untracked and Restoring Partially</title><link>https://takao.blog/en/web/git-stash-advanced-techniques/</link><pubDate>Wed, 20 Aug 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-stash-advanced-techniques/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Advanced git stash: Saving Untracked and Restoring Partially" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;In team development, you often need to switch branches to address an urgent bug fix while in the middle of writing code for a feature branch.&lt;/p&gt;
&lt;p&gt;While you can commit your half-finished work as a temporary &amp;ldquo;WIP&amp;rdquo; commit, a cleaner approach is to use &lt;strong&gt;&lt;code&gt;git stash&lt;/code&gt;&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;This article covers advanced &lt;code&gt;git stash&lt;/code&gt; techniques, including saving untracked files, labeling stash items, and restoring specific files from a stash.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="1-the-basics-of-git-stash"&gt;1. The Basics of git stash
&lt;/h2&gt;&lt;p&gt;Let&amp;rsquo;s review the most common commands:&lt;/p&gt;</description></item><item><title>Ignoring Formatting Commits in git blame with .git-blame-ignore-revs</title><link>https://takao.blog/en/web/git-blame-ignore-revs/</link><pubDate>Sun, 20 Jul 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-blame-ignore-revs/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Ignoring Formatting Commits in git blame with .git-blame-ignore-revs" /&gt;&lt;p&gt;When auditing a codebase to find out when and why a line of code was introduced, &lt;code&gt;git blame&lt;/code&gt; is a developer&amp;rsquo;s best friend. However, large styling updates, code formatter adoptions (like Prettier), or global linter autofixes can clutter this history. A single bulk reformatting commit can rewrite code authorship labels for the entire repository, hiding the original developers and commits that introduced the actual business logic.&lt;/p&gt;
&lt;p&gt;To solve this problem, Git (since version 2.23) introduced a native feature that allows developers to ignore specific commits during blame evaluations: the &lt;strong&gt;&lt;code&gt;.git-blame-ignore-revs&lt;/code&gt;&lt;/strong&gt; file.&lt;/p&gt;</description></item><item><title>Using git worktree for Concurrent Branch Development</title><link>https://takao.blog/en/web/git-worktree-multi-branches/</link><pubDate>Tue, 20 May 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-worktree-multi-branches/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Using git worktree for Concurrent Branch Development" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;In daily software development, it is common to get interrupted by an urgent hotfix request while in the middle of writing code for a feature branch.&lt;/p&gt;
&lt;p&gt;Traditionally, developers handle this in one of two ways:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Temporarily shelf active changes using &lt;code&gt;git stash&lt;/code&gt;, switch branches to fix the bug, commit, switch back, and run &lt;code&gt;git stash pop&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;Clone a completely separate copy of the repository into another directory to work on the hotfix.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;However, stash runs the risk of conflict errors on restore, and cloning multiple copies of the same repository wastes disk space and complicates local commit synchronization.&lt;/p&gt;</description></item><item><title>Automating Pre-Commit Checks with Husky and Git Hooks</title><link>https://takao.blog/en/web/git-hooks-husky-prevent-bugs/</link><pubDate>Sun, 20 Apr 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-hooks-husky-prevent-bugs/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Automating Pre-Commit Checks with Husky and Git Hooks" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;In team development, simple mistakes like committing code with syntax errors or bad formatting are common. These issues can break the CI build or lead to messy formatting wars during code reviews.&lt;/p&gt;
&lt;p&gt;Instead of relying on developer vigilance to enforce guidelines, you can automate these checks.&lt;/p&gt;
&lt;p&gt;By combining &lt;strong&gt;Git Hooks&lt;/strong&gt; with &lt;strong&gt;Husky&lt;/strong&gt;, you can automatically trigger linters (ESLint), formatters (Prettier), and unit tests (Jest) before any commit or push is finalized. This guide walks you through setting up this workflow.&lt;/p&gt;</description></item><item><title>Safe Usecases of git cherry-pick for Specific Commits</title><link>https://takao.blog/en/web/git-cherry-pick-usecases/</link><pubDate>Tue, 25 Mar 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-cherry-pick-usecases/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Safe Usecases of git cherry-pick for Specific Commits" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;In team development, you often encounter situations where you need to deploy a specific bug fix from an ongoing feature branch to your production branch (&lt;code&gt;main&lt;/code&gt;) immediately, without releasing the half-finished feature itself.&lt;/p&gt;
&lt;p&gt;Merging the entire branch would pull in unfinished code.&lt;/p&gt;
&lt;p&gt;This is where the &lt;strong&gt;&lt;code&gt;git cherry-pick&lt;/code&gt;&lt;/strong&gt; command comes in handy. This article reviews how to safely apply individual commits to a target branch, handle conflicts during execution, and avoid common history pitfalls.&lt;/p&gt;</description></item><item><title>Cleaning Commit History with Interactive Git Rebase</title><link>https://takao.blog/en/web/git-rebase-interactive-flow/</link><pubDate>Thu, 20 Feb 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/git-rebase-interactive-flow/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Cleaning Commit History with Interactive Git Rebase" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;During daily software development, it is common to end up with a messy commit history full of logs like &amp;ldquo;WIP,&amp;rdquo; &amp;ldquo;fix typo,&amp;rdquo; or &amp;ldquo;testing deployment.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;If you merge these commits directly into your main branch, finding where a specific bug was introduced or understanding why a line of code was added becomes extremely difficult.&lt;/p&gt;
&lt;p&gt;Git&amp;rsquo;s &lt;strong&gt;interactive rebase (&lt;code&gt;git rebase -i&lt;/code&gt;)&lt;/strong&gt; allows you to clean up your commit history before creating a pull request. You can squash multiple commits into one, edit commit messages, reorder history, or delete redundant changes. This article covers the step-by-step workflow of utilizing interactive rebasing.&lt;/p&gt;</description></item><item><title>Git Tutorial: From Basics to Advanced Workflows</title><link>https://takao.blog/en/web/how-to-git/</link><pubDate>Sun, 10 Sep 2023 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/how-to-git/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Git Tutorial: From Basics to Advanced Workflows" /&gt;&lt;h1 id="git-tutorial-project-management-and-version-control-fundamentals"&gt;Git Tutorial: Project Management and Version Control Fundamentals
&lt;/h1&gt;&lt;p&gt;Git is the de facto standard for version control in modern software development. It tracks every change to your codebase, enables seamless team collaboration, and provides safety nets for experimentation. Whether you are a solo developer maintaining a personal project or part of a large engineering team, mastering Git is essential. This guide covers Git from first principles through advanced workflows, with practical commands and real-world scenarios.&lt;/p&gt;</description></item></channel></rss>