<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Workflow on Commentary of Takao</title><link>https://takao.blog/zh-tw/tags/workflow/</link><description>Recent content in Workflow on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Commentary of Takao</copyright><lastBuildDate>Wed, 15 Jul 2026 22:01:08 +0900</lastBuildDate><atom:link href="https://takao.blog/zh-tw/tags/workflow/index.xml" rel="self" type="application/rss+xml"/><item><title>從 git checkout 遷移到 git switch 和恢復</title><link>https://takao.blog/zh-tw/web/git-checkout-restore-switch-commands/</link><pubDate>Wed, 25 Mar 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-checkout-restore-switch-commands/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-checkout-restore-switch-commands-zh-tw.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 vs Git Rebase: Operational 指南lines</title><link>https://takao.blog/zh-tw/web/git-merge-vs-rebase-best-practice/</link><pubDate>Wed, 25 Feb 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-merge-vs-rebase-best-practice/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-merge-vs-rebase-best-practice-zh-tw.png" alt="Featured image of post Git Merge vs Git Rebase: Operational 指南lines" /&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;</description></item><item><title>使用 git revert -m 安全地撤銷合併提交</title><link>https://takao.blog/zh-tw/web/git-revert-merge-commit-safe/</link><pubDate>Tue, 25 Nov 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-revert-merge-commit-safe/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-revert-merge-commit-safe-zh-tw.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 stash: Saving Untracked and Restoring Partially</title><link>https://takao.blog/zh-tw/web/git-stash-advanced-techniques/</link><pubDate>Wed, 20 Aug 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-stash-advanced-techniques/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-stash-advanced-techniques-zh-tw.png" alt="Featured image of post 進階 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>使用 git worktree 進行並發分支開發</title><link>https://takao.blog/zh-tw/web/git-worktree-multi-branches/</link><pubDate>Tue, 20 May 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-worktree-multi-branches/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-worktree-multi-branches-zh-tw.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>gitcherry-pick 用於特定提交的安全用例</title><link>https://takao.blog/zh-tw/web/git-cherry-pick-usecases/</link><pubDate>Tue, 25 Mar 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-cherry-pick-usecases/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-cherry-pick-usecases-zh-tw.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-tw/web/git-rebase-interactive-flow/</link><pubDate>Thu, 20 Feb 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/zh-tw/web/git-rebase-interactive-flow/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/git-rebase-interactive-flow-zh-tw.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></channel></rss>