前言
最近在Youtube上看到了一個訂閱很少當內容很紮實的Youtuber-码农高天，把很多Python底層觀念講的很清楚。
雖然訂閱人數很少(我看到的時候可能還不到70)，當內容品質蠻高的，尤其是更新速度非常快。所以就想說應該是本來就有在B站經營只是慢慢把內容搬過來而已，於是就去找了一下他的B站，然後剛好看到了這部十分钟学会正确的github工作流，和开源作者们使用同一套流程，講解的非常清楚，就順便做了一下筆記供以後自己查閱了(´▽｀)
以下內容核心主要來自他的影片，部分經過我個人的重新潤飾修改。
初始狀態
- Remote：Github上的倉庫
- Local：本地的Git倉庫
- Disk：本地源文件
在本地修改
從遠端獲取程式碼
[!NOTE] 目的
讓本地擁有一份遠端的程式碼，才可以開始工作
git clone <倉庫URL>
建立本地分支
[!NOTE] 目的
避免直接更動到原始內容(本地的)
git checkout -b my-feature
這樣做的好處有
- 不會搞壞主要分支
- 有利於多人合作
本地修改內容
修改完之後建議檢查看看有更動哪些內容
git diff
之後就可以把要保存修改的文件添加進git暫存區
git add <changed_files>
確認所有加入的文件後，就可以保存這筆更動(Commit)了
git commit
把內容推上雲端
把本地分支推上雲端
git push origin my-feature
此處指定把my-feature分支推上origin這個來源
狀況：遠端main已經有額外更新
這個時候我們必須要優先考慮遠端main的更新在目前要推上去的內容是否正常運作
所以會需要再把遠端的更新同步到本地合併先
取得遠端新版本
為了要更新main分支，要先切換到它
git checkout main
然後再把遠端的main同步到本地的main
git pull origin master
用rebase把內容合併
再切換回來原本修改內容的分支my-feature
git checkout my-feature
把main的內容合併進來，使用rebase方法
git rebase main
Git rebase 快速解釋：
- 自己的修改放到一旁
- 把目標分支(
main)的修改拿進來 - 在此基礎上，把原本的commit放進去
- 過程中可能會產生rebase conflict
- 需要手動選擇要哪個部分
[!hint] 這樣做的好處
相當於在遠端的main上更新了目前版本的內容
也是使用rebase而非merge的原因(基於遠端內容的變更)
推上遠端分支
因為做了rebase，所以必須要用-f才能推上去（不過是自己的分支，所以影響應該還好）
git push -f origin my-feature
把更新合併到main(pull request)
[!question] 為何叫做Pull request？
因為認為主要分支是屬於項目的，而功能分支是屬於個人
Pull request就是請求項目主人，把新分支的改變pull到項目中
項目主人審查完要更新的程式之後，一般會使用squash and merge來合併
[!question] 為什麼要做squash操作？
每次pull request的時候，功能分支上可能會有多個commit（且可能比較混亂）
希望維持主要分支的commit history能盡量簡潔
尤其希望在main中的每一個commit都能正常運作
當合併被接受之後，更動就正確的被納入處理了。
不過最後還需要做一點收尾的動作
收尾處理
[!hint]
原本的順序是先刪再更新
根據彈幕建議&個人經驗，調整成先確定更新沒問題再刪除
更新本地主分支、刪除功能分支
git checkout main # 切換到本地main
git pull origin main # 更新main分支
git branch -D my-feature # 刪除功能分支
此時就可以讓三個不同地方的內容是一樣的了
若有新的更新，就再開啟下一個循環
刪除遠端功能分支
一般來說在Github上會有可以直接刪除的按鈕
這樣就可以刪除遠端的分支了