# Outline
一、前言
二、論述
A、待敘項目

# TL;DR
...

# Updated
2019-10-06: 更新標題文章結構

在雙十連假前，此系列文每天的發文時都會以最簡陳述為主，以求在繁忙的日常中，至少能先維持挑戰鐵人賽的進度，並且逐漸拓展思路與系列結構。預期會在國慶連假將本篇文章論述完整。

一、前言

在前面幾天聊了許多 Git 其所然的資訊後，今天就透過這些概念，再去看以前只知 Git 其然的操作吧！

二、論述

在我們對當前的 Repository 進行更動時，這些現在進行式的狀態，就是所謂的 Workspace，Git 會拿 Workspace 的狀態和 index / staged 的狀態做比對，讓我們知道發生了哪些變動。index / staged 的狀態也會被拿去和當前 HEAD 所在的 commit 的 tree 做比較，預設是和該 tree 相同的狀態，直到有變動從 workspace 被加入到 index / stage 中。

被變動加入到 index / stage 時，該檔案就算是正式被 Git 儲存起來。Git 不是儲存變動，而是透過比較得知變動，所以變動過後的檔案，會被 Git 視為另一個檔案儲存起來。

當我們 Commit，Git 就會將 index / stage 的狀態儲存成一個 commit。然後 HEAD 所指向 branch 所 Refer 的 commit 就會自動轉到新的 commit，但是 tag 會留在原本的 commit 上。因為 HEAD 預設是指向某個 branch，所以自然會隨之移動，若是 HEAD 原本指向的是某個 Commit 而不是 branch，那再提交一個新的 commit 後，HEAD 就會像 branch 一樣，重新指向最新的 commit。

當我提交了數個 commit 後，發現這些 commit 不是我要的，就可以透過 reset 的方式，改動當前分支所 refer 的 commit，回到最初或者另外想指定的地方。當原本 branch 在 reset 前所 refer 的 commit 沒有被任何 reference 參考到，就會從 Git 的線圖上消失。但正如我們對 Git 儲存方式的了解，事實上這些 commit 還是存在的，直到 Git 的回收機制被觸發，才會真的被移除。所以若是 reset 後後悔了，只要能查到 git commit 的 SHA-1 值，還是可以重新透過 branch 或 Tag 去重新參考，當這些 commit 被重新觀測到後，自然就會重新顯示在線圖上。

但若是我們不要的 commit 已經推送的遠端的 repository，就不會建議用 reset 的方式進行撤銷，畢竟會導致協作上的混亂。所以這時候就會透過 revert 的方式進行，當我要 revert 某個 commit 時，Git 就會比對該 commit 與前一個 commit 的差異，並且將變動進行反向，生成一個新的 commit，這樣v這些變動就會互相抵銷了。所以當我們在 revert 時，記得要從最新的 commit revert 回去，才容易有衝突或錯誤的情況，就有點像是後進先出的概念。

附錄 A、待敘項目

• Git Reset
• 設計實驗與範例程式碼