連結遠端 git remote add origin

用於將你的本地 Git 儲存庫與一個遠端儲存庫建立關聯。它讓你的本地專案能夠連結到遠端的伺服器，以便之後可以將本地的變更推送到遠端，或是從遠端拉取新的變更。
git remote add: 這個指令是用來新增一個遠端儲存庫的連線。
origin: 這是你為遠端儲存庫取的名字，origin 是最常見的預設名稱，用於代表那個遠端儲存庫的 URL 位址。你也可以自訂其他名稱。
: 這是你新增的遠端儲存庫的實際 URL，可以是 HTTPS、SSH 或 Git 協定的連結。

設置與初始化

初始化專案 git init
在當前目錄建立一個空的 Git 專案（建立 .git 資料夾）。
配置使用者 git config --global
設定全域使用者名稱與 Email，這是提交記錄的身份證明。

存檔與檢查 (本地端)

檢查狀態 git status
顯示工作目錄與暫存區 (Staging Area) 的檔案狀態。
納入暫存區 git add 或 git add .
將指定檔案或所有變更 (.) 移入暫存區，準備提交。
git add
只將指定檔案的變更（新增、修改、刪除）納入暫存區。
git add .
將當前目錄下（含子目錄）所有被追蹤的檔案的變更納入暫存區。
提交變更 git commit -m "msg"
提交暫存區的內容至本地倉庫 (Local Repository)，-m是--message的縮寫，後面""裡面填寫此次commit的提交資訊(ex:修改了文字顏色、新增span標籤等等)。
檢查歷史 git log --oneline
以簡潔的單行格式顯示提交歷史紀錄。

分支管理 (Branching)

單純創建分支 (不切換) git branch
創建一個新的分支。
創建並切換 git switch -c --create
創建一個新的分支並立刻切換過去。
切換分支 git switch
切換到一個已存在的分支（取代舊的 git checkout）。
顯示所有分支 git branch
顯示所有本地端分支列表，並標示目前所在的分支。
合併分支 git merge
將 的所有變更，合併到你目前所在的分支。歷史線會保持分叉狀態（非線性）,提交圖 (Graph) 會比較凌亂，有很多分叉點。合併分支「可能產生衝突 (Conflict)」，如產生衝突。
衝突Conflict) 當執行 git merge 且發生衝突時，Git 會自動暫停合併程序，並進入 「衝突狀態 (Conflict State)」。

衝突(Conflict)：

1.終端機顯示： Git 會提示 Automatic merge failed; fix conflicts and then commit the result.
2.檔案內容變化： 衝突的檔案會被 Git 標記出來，檔內會出現特殊的標記符號，告訴你哪些程式碼是你這邊的，哪些是別人的。
3.
html

<<<<<<< HEAD (或你的分支名稱)
<div>這是你改的黃色背景。</div>
=======
<div>這是隊友改的綠色背景。</div>
>>>>>>> <對方的分支名稱或提交 ID>

HEAD 到 ======= 是你當前分支的內容。

======= 到 >>>>>>> 是要合併進來的分支的內容。

衝突(Conflict)解決方式：

1.手動編輯： 打開衝突檔案，刪除 <<<<<<<、=======、>>>>>>> 這些標記，並決定最終要保留或組合哪些程式碼。

2.納入暫存區： 編輯完成後，表示你已手動解決衝突。必須執行 git add ，告訴 Git 「這個檔案的衝突我已經解決好了」。

3.提交解決結果： 執行 git commit。這次提交會是那個特殊的 Merge Commit，表示合併流程成功結束。

遠端協作 (Remote)

下載並合併 git pull
從遠端倉庫下載最新的變更，並自動與當前分支合併,相當於做這兩個指令(等於fetch + merge)。
上傳變更 git push -u origin (專案中第一次上傳並在遠端設置新分支且連結遠端新分支)
會執行以下三點：
1.上傳我本地 的所有提交到遠端。

2.在遠端建立一個同名的 分支。

3.設定我本地的分支永遠追蹤遠端這個新分支。
-u為 --set-upstream 的簡寫，設置追蹤關係，讓之後的 push 不用再指定遠端名稱，只需要輸入git push即可套用同個上傳位置。
上傳變更的縮寫 git push
在已建立追蹤的git push -u origin 的遠端 origin上的 分支當中進行提交上傳

手動增加追蹤關係 git branch --set-upstream-to=origin/
當第一次上傳變更 git push -u origin 如果忘記打 -u 也就是 git push origin ，這時，你從遠端拉分支或推分支上去，每一次要執行都要打完整指令 git pull origin ， git push origin ，顯得有些麻煩，這時就可以將本地連結到遠端的origin/ 分支上，使用git branch --set-upstream-to=origin/，即可手動完成本地及遠端分支的追蹤，讓你在想拉或推分支時，可以只打 git push、git pull。

後悔藥 (還原/復原)

丟棄本地修改 git restore
丟棄工作目錄中對該檔案的所有未暫存 (Unstaged) 修改，回復到上次提交或暫存的狀態。
取消暫存 git restore --staged
將檔案從暫存區 (Staging Area) 移回工作目錄 (Working Directory)，但不丟棄修改內容。

不輕易使用的

改變基底 「重寫歷史」或「線性化歷史」 git rebase
提交記錄會變成一條直線（線性）提交圖會非常整潔，為了追求歷史的簡潔線性，它犧牲了「開發過程的歷史真相」，導致看不出專案有沒有合併過。
rebase 創建了新的提交，讓分支指針指向新的歷史線。舊的提交雖然被「棄用」，但在 Git 的資料庫中（.git 資料夾），看起來像是隱藏起來，但舊的提交資料本身並沒有立刻被刪除。Git 系統會暫時保留這些提交，直到一段時間後才會被機制清除。
絕對不要對任何你已經 push 到遠端（公開分享給隊友）的分支執行 rebase， 否則隊友下次 pull 時，他們會看到兩個不同的歷史紀錄，因為 rebase 會產生新的提交 ID。如果你的隊友拉下了舊的 ID，你又把新的 ID 推上去，兩人的電腦會因此歷史不同步而陷入混亂，需要花大量時間來解救。
挑選提交，精準修復 git cherry-pick
單點修復或轉移。當你只需要將某個分支中的「單一、關鍵的提交」，搬到當前分支使用，(如當前所在分支並非你想要搬(接收變更)的地方，可用git switch切換到你想搬到的 地方(目標接收分支，例如 main)，再使用git cherry-pick )。
指的是（Commit）的獨特身份證號碼(ex:5a76f2b3c6e6)， 需透過 git log 查詢。

.gitignore
是一個配置檔案，用來告訴 Git 系統：「在這個專案裡，有些檔案或資料夾是雜物，你永遠不要追蹤它們的變化，也不要把它們提交到遠端。」。
通常會忽略那些不應該分享給隊友或會自動產生的檔案，例如套件資料夾：node_modules等等。

基礎流程模型：從零到協作

以下是你在專案中每天會重複的「黃金四步」：

1. 啟動專案
   設定身份：

git config --global user.name "Your Name"
git config --global user.email "your@email.com"
建立專案：

git init
2. 開工流程 (避開 Main)
開工第一步（更新）：

git pull
開分支工作（確保 Main 安全）：

git switch -c feature/your-name-login
3. 提交與上傳
檢查狀態：

git status
加入暫存區：

git add .
本地存檔：

git commit -m "feat: 完成登入頁面 UI 結構"
第一次上傳（設定追蹤）：

git push -u origin feature/your-name-login
（之後都只需要 git push 即可）

題外話：

為何git儲存要使用git add跟git commit兩個指令，不能合併成一個commit指令?
答案是commit的儲存速度跟原子性。

儲存速度：

當你在電腦儲存檔案的時候，是不是有類似經驗?儲存某個容量很大的檔案要幾十分鐘或一小時，但是儲存一個容量很小的檔案(例如一張照片)，可能只需要一秒甚至一秒不到。這跟git的設定的原理一樣，因為如果只用一個指令做這兩個步驟，時間可能要5分鐘，但當你分成git add跟git commit，雖然也是要五分鐘，但最花時間的是git add，
因為執行的步驟或內容較多，反之，commit可能只佔據那五分鐘的幾十秒或幾秒鐘，你說這樣有比較好嗎?當然!你想像上面的例子，假設你儲存一個很大的檔案，儲存到一半失敗了，你想要儲存，就只能重新儲存，是不是就會覺得想「儲存」得快一點，以免儲存到一半就失敗，還要重新來過，而儲存會分成git add跟git commit兩個指令的原因，就是這個讓儲存速度變快，減少失敗的道理。

原子性：

commit有個原子性的特性，所謂的原子性，就是只會有全部成功或是全部失敗，不會有第三種情況，所以如果你把git add跟git commit兩個指令合併成一個commit指令的話，把儲存的時間拉得更久，失敗機率就會變得越高，這樣就失去git版本控制的靈活性了，你說把儲存時間拉得越長，失敗機率就會變得越高，這我還能理解，但為何會失去靈活性?表面上指令看起來兩個變一個，不是簡化了嗎?表面上是這樣，但Git有個最重視的設計原則「歷史的完整性」，如果每次 commit 都可能是一個 「部分成功/部分失敗」 的狀態，這樣在設計上面，開發者可能會需要在系統寫個失敗選單，每次查看歷史都要先看那歷史有哪些檔案沒成功，假設有沒成功儲存的檔案，那又要再跑去把失敗的檔案再儲存一次，這樣是不是顯得更麻煩?所以git commit的設定就是遵循這個原子性，讓你看到一個 Commit 時，你不需要問問題。你知道它是對的。因為儲存全部成功才會看到歷史點，而失敗就會當作全部失敗，不會讓你儲存，也就不會看到歷史點。