本文整理了您熟悉 Git 基本工作流程後會遇到的三個主題：如何建立儲存庫（透過 git init 或 IDE）、rebase 和 merge 有什麼不同，以及機密資料不小心進入歷史時，該怎麼妥善移除。這三個主題在使用 Claude Code 時也用得上：它會透過指令執行這些操作，而您需要了解指令背後發生了什麼。

範例和介面截圖使用 JetBrains IDE；依您使用的版本不同，操作名稱和位置可能會不一樣。練習時請使用獨立的練習儲存庫。在工作專案中，請遵循該專案的分支、提交和推送規範。

使用 git init 或 IDE 建立儲存庫

如果專案已經在 GitHub 上，您可以將它 clone 下來。另一種情況是，您手邊有一個放著程式碼的本機資料夾。git init 會在裡面建立 Git 的內部資料，但不會建立第一個 commit。以下範例假設 README.md 和 .gitignore 已建立並檢查過；其他需要的檔案則另外加入。

git init
git status
# 檢查 README 和忽略規則後
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"

在 IDE 中建立本機儲存庫，請使用建立 Git 儲存庫或啟用版本控制的功能。Share Project on GitHub 是另一種流程：它也會建立遠端儲存庫，並提示您推送。推送前，請檢查選取的檔案、歷史紀錄和可見度。

Kotlin

Public 還是 private

建立儲存庫時，您可以選擇它的可見度：

  • public - 所有人都能在網路上看到這個儲存庫，也能查看程式碼。適合放作品集或 open source 專案；
  • private - 只有您和受邀的人能存取。對於不適合公開的工作或練習程式碼，這是預設選項。

可見度不是一成不變的：之後仍可在 GitHub 的儲存庫設定中變更。

與 Claude Code 的關聯

Claude Code 可以替您執行 git init，並準備第一個 commit。如果 GitHub 上還沒有儲存庫，它也能透過 GitHub CLI（gh repo create）建立一個。這時由您決定要設為 public 還是 private。

rebase 和 merge 有什麼不同

merge 和 rebase 都是為了把一個分支上的工作帶到另一個分支，但做法不同，專案歷史最後長什麼樣子也取決於此。

merge 會合併兩段歷史。如果兩邊已經分歧，通常會建立一個有兩個父提交的 merge commit。如果目前分支是另一個分支的祖先，Git 也可能直接 fast-forward，不建立新 commit。下方圖示呈現的是分歧後的分支。

上方是 main 分支，下方是 feature。合併後，main 指向 M，而 M 有兩個父提交：E 和 D。ABEMCD
上方是 main 分支，下方是 feature。合併後，main 指向 M，而 M 有兩個父提交：E 和 D。

merge 會保留兩條線，並加入一個 merge commit；從歷史紀錄中可以清楚看出曾經有獨立的 feature 分支。

rebase 會搬移您的 commit，讓它們看起來就像是從目標分支最新的頂端開始工作的。歷史會變成一條直線。不過這也有代價：rebase 會改寫您的 commit，舊的會被帶有不同 hash 的新 commit 取代。

main 分支指向 E，feature 分支在 rebase 後則指向新的 D2。圖中未顯示 B 之前的共同歷史。BEC2D2
main 分支指向 E，feature 分支在 rebase 後則指向新的 D2。圖中未顯示 B 之前的共同歷史。

rebase 後，C 和 D 看起來像是接在 E 之後建立的：歷史變成線性，但它們已是帶有不同 hash 的新 commit（C2、D2）。

該怎麼選？

  • merge - 需要保留真實的歷史紀錄，或分支是共用的時候。這是預設的安全選擇；
  • rebase - 在建立 pull request 前整理自己的個人分支，線性的歷史更容易閱讀。
請留意

在您還在熟悉 rebase 的階段，請只在自己尚未推送的分支上使用。若要改寫其他人也在使用的分支，必須遵循協調好的流程，否則同事那邊會留下舊的歷史紀錄。如果不確定會造成什麼影響，先停下來確認專案規範。

請留意

整合方式取決於任務和專案規範。不要依賴代理自行假設的預設做法：請它在執行前說明目標分支、操作方式，以及對歷史紀錄的影響。

從儲存庫移除機密資料

透過新 commit 刪除檔案，並不會清除舊 commit 中的機密資料。如果密碼或 token 已被其他人取得，請先向發出該憑證的服務撤銷或更換它。清理歷史紀錄也無法收回別人已經複製走的內容。

請留意

不要把清理共用歷史紀錄當成一般的檔案修正來執行。這會改變 commit 識別碼，因此需要協調：停止推送舊分支、確認所有受影響的路徑、在獨立副本中檢查結果，並和同事約定如何更新各自的副本。

GitHub 說明了如何使用 git-filter-repo 進行清理。實際指令取決於您要刪除整個檔案，還是替換機密字串，以及該字串出現的位置和歷史紀錄流向。請依照官方移除敏感資料指南操作，其中包含建立全新副本、檢查結果、更新遠端參照，以及同事需要採取的動作等步驟。

清理本機副本本身不會改變伺服器上的內容。強制推送已改寫的歷史是另一項需要事先協調的操作，這裡不需要執行一套適用所有分支的通用指令。別人的 clone 和 fork 中的副本不在您的掌控之中；至於 GitHub 上仍可存取的參照和快取，請依照同一份指南中的條件聯絡 GitHub Support。

若要降低再次發生的風險：

  • 將機密值存放在程式碼以外的位置，例如環境變數；
  • 在 Git 開始追蹤本機檔案之前，先將 .env 這類檔案加入 .gitignore；
  • commit 前檢查選取的檔案，並執行 git diff --cached；
  • 如果儲存庫支援 secret scanning 和 push protection，請啟用它們作為額外檢查；但它們無法偵測所有可能的機密資料。
C++
請留意

代理可以協助找出受影響的路徑並擬定清理計畫。不要把有效的機密資料貼到聊天中搜尋。先撤銷存取權，再協調如何處理歷史紀錄。

搭配 Claude Code 時如何運作

Claude Code 操作儲存庫時，這三個主題都會出現。請留意以下幾點：

  • 它可以初始化儲存庫（git init）並準備第一個 commit；在 GitHub 建立儲存庫時，public 或 private 由您自行選擇；
  • 它會依照專案規範提出整合方式；執行前，您仍要確認 merge 和 rebase 的影響；
  • 它看得到哪些檔案會進入 commit，但確保機密資料不會混進去，最後仍由您負責。
請留意

commit 前，請同時檢查檔案清單和 diff 中的內容。機密資料可能藏在一般的原始碼檔案裡，不只會出現在 .env。如果它已經進入歷史紀錄，請先更換受影響的機密資料，再評估是否需要清理歷史。

上一篇文章：復原與還原 Git 中的變更