在 Day 21 提到了兩種讓共用儲存庫的線圖更整齊好閱讀的方法，分別是：

1. 整理在一直線：在更新到遠端儲存庫之前，先針對目前的遠端儲存庫操作一次 rebase，而後才 git push 到遠端共用儲存庫。在更新遠端儲存庫狀態的時候，可以操作 git pull --rebase。
   

2. 讓每次的完成的任務，在併入主要分支的時候，除了要對共用儲存區 rebase 外，也都使用 --no-ff 參數進行 merge，讓每個任務都形成一個迴圈，方便找到整個任務相關的 commit。在 master 分支 merge 的時候可以使用 git merge --no-ff。
   

談談 merge 壓縮 git merge --squash

在實務上，還有一個的作法，會採用只讓每次任務的成果一次回到主要分支上，而因任務所建立的分支繼續留在原處方便未來有需要時查詢使用。單純用說明的似乎有點模糊，我們以 Day 21 提到的 apple、banana、cake 及 dog 四個分支為例，直接展示成果：

如上圖，對於 master 分支而言(藍色的線)，上面一定都是合併後的成果，如果真的有需要查詢每個合併點實作的細節，也都還可以找到該分支進行確認。如果只關注 HEAD 所前所在分支，也可以如下圖一樣，在 SourceTree 將 branch 的選項切換為 Current Branch，就可以僅看到 master 上的變化。

這個合併的流程，在一些常見的共用儲存庫工具中，如 GitHub、GitLab 也常常採用，當同時更新到共用儲存庫的人很多，但又來不及做 rebase 時，GIT 的線圖也不至於太難懂。

目前介紹的這三種流程，在之後提到 gitflow、GitHub Flow、GitLab Flow 也都還會再提到，適合在了解這些常見的流程之前，先行了解。

續談 git revert

在比較早的天數如 Day 09 我們談到 git reset，可以用在想改寫已經進入到儲存庫的 commit 時；還有 Day 11 提到 git checkout 以及 GIT 2.23 之後提供的 checkout 替代方案 git restore，可以用在復原尚未進入儲存庫的原始碼檔案變更。

其中對於已經更新本地儲存庫資料到遠端共用儲存庫的 commit 來說， git reset 建議只在尚未更新到遠端儲存庫時使用：

一來如果 reset 的對象是已經更新到共用儲存庫的 commit 時，變動後的 commit ，再次的更新到遠端，遠端會判別為新的 commit，而不允許直接更新遠端儲存庫，縱使只是修改 commit message。

二來，當更新的目標是許多人共同使用的儲存庫分支時，再進行 git push -f 之後，會造成其他使用該共用儲存庫分支的使用者須以比較麻煩的方法更新本地儲存庫。

那，已經更新到共用儲存庫的 commit 要怎麼後悔呢？可以使用 git revert 指令，它的概念用樂高解釋大概是這樣，現在有一個步驟記錄的內容是：在基板的右邊碟上一塊綠色的樂高積木。

那麼針對這個步驟來說，所謂的 git revert 也就是，新增一個步驟，把基板右邊的這一塊綠色樂高積木移除。

在 GIT 上怎麼實作呢？

假設現在有一個儲存庫，目前有兩個 commit，現在想要復原第二個 commit 對應的 HASH Code 是 175094d，在這個 commit 中，我們新增了一行原始碼內容為：banana

這時好要進行 revert 動作，僅需要執行指令：git revert 175094d

在 SourceTree 的線圖上可以看到新增的這個 revert commit 與預設的 commit message 以及對應的內容。

如何使用 SourceTree 實作呢？

在 GUI 上，只需要在想要 revert 的 commit 上點選右鍵，選擇「Revert commit…」選擇後 SourceTree 即會完成新增 revert commit 的動作。

動畫如下：

總結：

今天談了兩個內容，分別是 git merge --squash 不太一樣的 GIT 合併策略以及 git revert 新增一個反向動作的 commit，用來復原已經在共用儲存區的 commit。

這兩個小主題，單獨提出來講幅度可能沒辦法講太多，於是把這兩個內容合併在一起分享。這兩個小主題，也都是之後在 GIT 流程中可能會提到的內容。