系列文的圖片就靠它了
上一篇《版本控制的藝術：Git 基礎篇》介紹了 Git 的安裝與推送到遠端倉庫的基本操作。雖然這一篇名為「實務篇」，但其實並沒有太複雜的概念，主要是根據我的實務經驗，分享開發者 A 與我本人的協作過程，以及一些需要注意的事項。熟練這些操作後，基本上就能成為一名在 Git 方面合格的工程師了。
我們已經在 GitHub 推送專案，在實務面上，接下來就是要開發新功能與修 bug 啦！為了避免太過混亂，本篇就以兩人協作（假設名為 Hank 和 Alan）的方式來做說明，多人以上其實概念都差不多，可能就是比較頻繁的 git pull 和解衝突。
首先模擬一下接到新的需求，假設目前需要解一個 bug 與開發一個新增功能，我們到該專案之下個別建立 issue：
請忽略兩個 assignee 都是同個人 XD
回到 VSCode，我們確認目前位置在主支以及與與遠端倉庫版本一致
# 檢查是否在主支
git status
# 拉取最新主支
git pull origin main
*記得把你的遠端倉庫地址添加到 origin，才不需要每次都複製
出現 Already up to date 就是最新了
接下來 Hank 就必須建立該 issue1 的分支去處理 Bug；Alan 去建立 issue2 的分支去完成 feature
# 新增分支並且切換過去（Hank）
git checkout -b issue1
假設 Hank 已經處理完 bug
# 添加至暫存區
git add .# commit 並且添加訊息
git commit -m "bugfix 已解決格式問題"
# 確認本地是最新, 再來本地端合併主支測試
# git fetch
git pull origin main
git rebase main
# 推送上 GitHub
git push origin issue1
*通常協作團隊都會有自己的 Git Rules，請務必按照團隊格式的要求，不然會被退 PR(我一定會退 XD)
推送完成之後，到 Pull Requests 頁面新增請求，雙人開發的話就是兩人互相 Review，多人的話可能會有一名管理主支的資深工程師，一切都按照團隊 Git Rules 去執行
建立 Pull Request(PR)
Review 完確認沒問題之後，管理主支的工程師就會把分支合併去主支
合併完成 可喜可賀
接下來說明很常遇到的問題，如果 Hank 修改的 bug 與 Alan 新增功能的程式碼有部分重疊，這個時候很可能推送的時候會發生衝突(conflict)，通常都是誰做得慢誰去解衝突XD
# 建立分支的時候大家都是共同的起點, 但是 Alan 做得比較慢,
# 此時遠端已經是合併issue1後的 main
git add .git commit -m "feat 新增功能"
# 確認本地是最新, 再來本地端合併主支測試
# git fetch (此時會發現有最新的 main, 哭啊!!可能要解衝突了)
git pull origin maingit rebase main
如果出現類似以下畫面
衝突
恭喜你，你要負責解衝突了。此時會看到需要解衝突的文件會變成紅色，也不用這麼緊張，就是手動確認程式哪部分要留、哪部分要刪
Hank 搞什麼鬼啊!!!
確認完成後把一些冗餘的資料刪除
終於修完衝突了
然後再
git add .
# 繼續 rebase
# 這邊會跳出 vim 編輯, 通常不需要特別改 commit, 直接 :wq 儲存離開
git rebase --continue
# 推送到分支 issue2
git push origin issue2
*有的團隊在解衝突會要求寫下 commit，一切都是依團隊的 rule 行事
後面的建立 PR 程序就跟前面的 issue1 一樣，再來就可以看到 issue1 與 issue2 都合併進去主支啦！Git Graph 可能類似於
合併回主支 main
以上就是 8 至 9 成協作的基本流程，當然可能還有其他不同的方式，只是我尚未有相關的經驗。這些內容都是基於我的實際經驗分享，希望對大家有所幫助。下一篇《版本控制的藝術：自建 Git Server — Gogs Web》將會介紹我在封閉網域中自建 Git Server 的過程。如果以上內容有任何說明不當或不清楚的地方，歡迎留言讓我知道，謝謝！
