前言
我們來整理一些 Git 的基本知識
檔案的狀態
討論 git 之前，我們可以先知道檔案在電腦中可以有四種狀態，
我們可以用下面的圖作解釋
untracked files: 未追蹤的檔案
不在 git 控制範圍內的檔案，也就是說就算變化了，
因為不在 git 所觀察的範圍，因此與我們無關
例如：電腦中，與 git 無關的其他資料夾的檔案
unmodified files: 未編輯的檔案
這個概念聽起來有點繞口，有兩種狀況會變成這個狀態，
- 在 git 的範圍加入新的檔案，畢竟剛加入，就是個未編輯的狀態(也可以說已經編輯完了，成為一個定版的狀態)
- 當我們決定替現在的 git 目錄提交一個定版 (commit)，那麼現在的檔案狀態就是未編輯的狀態 (這裡「相對的基準點」就是定版的狀態，因此是未編輯的狀態)
modified files: 編輯中、已編輯的檔案
一樣這個概念聽起來有點繞口，不過如果上面已經有理解了什麼是「未編輯的狀態」 (最難理解的點應該是在「相對基準點是定版」)，
這裡就很好懂了，只要有修改，就是 modified files。
staged files: “等待”定版的檔案
這裡的概念與 modified files 類似，甚至有些重疊的部分，
硬要分的話，一個檔案可以在定版前不斷的在 modified files 階段，也就是說我們可以一直修改他，
直到我們想提交定版 (commit)，就會是 staged files。
而在提交定版 (commit) 後，就會變回 unmodified files，因為「相對現在的定版狀態」，未編輯的檔案就是「沒有編輯的檔案」
git 中的版本控制
這裡與上面的概念有點重疊，但是又不太相同，
上面我們提到了檔案的狀態，而這裡我們要看 git 怎麼樣的控制檔案的版本。
repository (常簡稱 repo)
我們先講 repository (常簡稱 repo)，基本上可以當作是檔案版本的保存庫
暫時的定版 (git add) 與正式的定版 (git commit)
我們可以透過 git add，把檔案暫時都加入 staged files，
注意我們上面有一個微妙的定義「”等待“定版的檔案」
因此在 staged files 的這個階段，我們一直都沒有正式的上一個版本，一切都只是暫時(我們仍可修改)的狀態，
「當我們確定現在的修改程度，值得作一個版本記號」，我們就會下 git commit 提交定版，
也就是我們把 staged files 「正式的作為一個版本」保存在 repo 當中。
與雲端交互
學習 git 的時候，可以先不用學習雲端相關的知識，
因為在觀念還不穩時，加進雲端的概念只會更多更亂，
然而，git 是完全可以在本地執行的，如果新手建議可以先嘗試在本地用 git 進行版本控制即可。
與雲端交互的關鍵基本上就是 push 與 fetch (把本地推上雲端、把雲端拉回本地)，
但在此操作之前「絕大部分的操作，都是要我們在本地先處理好，在上雲端的」，
「請盡量不要上雲後再來處理，會比在 local 處理麻煩非常多！ 而 local 處理非常簡單！！！」
上面圖片基本上可以反覆查看，而與雲端交互的部分基本上可以晚點看
大原則就是「在 local 把一切都處理好，在一次 push 上雲。不要 push 上雲後再來後悔，會難處理很多」