苦隊友不會 Git 久矣。為了避免每次做專案教一遍 Git，推出這篇隊友必看的 Git 多人協作教程（舊文的推送，霧
學習 Git 需要多加實踐，熟能生巧方為正道
隊友要是連 Git 都不會，最好不要組隊了
本文部分參考 Git 多人協作教程 | 異國迷宮的十字路口
寫在最前#
什麼是 Git 存儲庫 Git Repository？ 一個專案，就是一個 Git Repository。更具體一些，專案文件夾的位置，就是 Git Repository。要想一個專案文件夾成為一個 Git Repository，需要運行 git init 命令創建本地 Git 倉庫（所謂本地，就是在自己的電腦上） 當然創建 Git 代碼倉庫也未必要本地，通過 Github 網站也可以創建 Git 代碼倉庫
什麼是 Git？ Git 是一個版本控制系統，對 Git Repository 的文件版本進行管理。保存了你對 Git Repository 的操作記錄。在需要的時候，可以從操作記錄中恢復歷史版本。
什麼是 Github？ Github 是托管 Git Repository 的網站。用戶可以將自己筆記本電腦上的 Git Repository 上傳到 Github 網站，然後在桌面上下載編輯，或者與其他人進行代碼同步與協作（比如大創，霧
安裝 Git 程序 可以參考 Git 官網 https://git-scm.com/ ，以及各大博客網站，不再贅述。
推薦通過命令行操作 Git 但對新手來說，稍有門檻。也可以通過圖形化界面操作。
Git GUI (圖形用戶界面 Graphical User Interface) 有很多 比如：Github Desktop, Sourcetree, GitKraken 以及各種 IDE 中自帶的 Git GUI 等均可使用。
具體安裝不再贅述，請通過 Bilibili 以及各大博客網站搜索。
從 clone 開始#
使用 git clone 命令從 Github 等 Git Repository 托管網站上下載我們需要的 Repository (代碼倉庫)。
如圖所示，就是我們所需的鏈接地址了。我們只需使用 git clone 命令，再加上我們複製得到的地址，就可以拉取我們想要的倉庫了。
git clone https://github.com/github/site-policy.git
此處代碼將拉取 github 官方的 site-policy 倉庫
如果使用命令行的方法克隆倉庫，需要注意，倉庫會被下載到命令行當前路徑下。修改路徑可用 cd 命令。具體可查閱各大博客平台。
如果有餘力，可以為 Github 配置 SSH Key，這樣就可以使用 SSH 協議 clone 代碼倉庫了 同樣，此處不再贅述。
當我們完成了代碼倉庫的 clone，意味著我們在自己的電腦上也有了一份和 Github 上一模一樣的 Git Repository。
我們將自己電腦上的代碼倉庫稱為 local repository，在 Github 或者其他托管網站上的代碼倉庫稱為 remote repository
❗❗打開電腦本地的 repository，或許你會發現一個名為 .git 隱藏文件夾，需要特別注意的是，這個 .git 文件夾保存了 repository 所有的修改記錄以及遠程連接信息 ❗❗如果將 .git 文件夾刪除，那麼當前專案就不再是一個 repository，而與普通文件夾沒有任何區別了。
Git 代碼更改與上傳#
前面我們說過，可以認為專案文件夾就是 Git Repository
對於代碼文件，不可避免地，我們會刪除一些錯誤，添加一些功能，這就涉及到文件的新建、刪除、修改。
按了 Ctrl+S，代碼倉庫就更新了嗎？ 並不是這樣。
Ctrl+S 快捷鍵可以保存文件，但不能更新 Git 的記錄。也就是說，在我們的視角下，代碼確實是修改了，但在 Git 的視角下，代碼並沒有發生改動。
關於文件新建與文件刪除，也是類似的情況。
那麼，如何讓 Git 也能察覺到文件的變動呢？
需要使用 git add 命令。
git add *
此處 * 是通配符，表示作用於所有文件。
其他用法可以參看 git add 命令 | 菜鳥教程 或各大博客網站的相關博文。
雖然 Git 察覺到了你對文件的修改（文件進入了暫存區），但並沒有生成操作記錄（修改沒有進入本地倉庫）。
既然這樣，如何更新 Git 倉庫呢？
需要使用 git commit 命令將修改提交到本地倉庫。此時，才會在 git log 中生成 “操作記錄”。
git commit -m "my first commit"
此處 -m 為 commit 操作傳入一個參數，作為本次提交的 message 通常這個 message 是對本次提交的一個概括。
commit message 模板 參考 conventional commits 或 Commit message 和 Change log 編寫指南 - 阮一峰的網絡日志 力求簡單明瞭。
git commit 命令的其他用法可以參看 git commit 命令 | 菜鳥教程 和其他教程資料。
至此，我們成功更新了 local repository 也就是自己電腦上的代碼倉庫
但隨之而來的是一個問題 —— 我們修改了 local repository 本地倉庫，但 Github 網站上的 remote repository 遠程倉庫，並沒有人動過，這時候，兩個倉庫出現了不一致。
我們把更新的版本（我們修改過的 local repository）上傳到 github 上，去更新 remote repository
這個過程使用 git push 命令
git push origin main
執行上述代碼後，本地的 main 分支會上傳並覆蓋遠程的 main 分支。
參考 git push 命令 | 菜鳥教程 查看更多語法細節。也可以查閱其他教程網站。
Git 代碼同步與下載#
當 github 上遠程代碼倉庫比自己電腦本機上本地代碼倉庫新的時候，我們需要下載代碼。
這時，可以使用 git pull 命令
git pull origin main
這時候，遠程代碼倉庫的 main 分支就會被拉下來，然後更新本地的 main 分支。
更多信息，可以參考 git pull 命令 | 菜鳥教程 和其他資料。
代碼衝突與解決 如圖是取自網絡的一個代碼衝突案例
<<<<<<<<<<<
A
===========
B
>>>>>>>>>>>
這個記號叫做衝突記號 如上，A 和 B 是互相衝突的。
一般 IDE 會自動識別衝突記號，然後將對應的衝突代碼高亮（圖中顯示為綠色和藍色）並給出衝突解決的快捷菜單：包括 Accept Current Change, Accept Incoming Change, Accept Both Change 和 Compare Changes。單擊對應的選項，就可以實現兩段代碼二選一。
有時候，衝突記號不能被正確識別，就需要手動刪除重複代碼和衝突記號，否則合併會出錯。
實際上，在代碼 push 的時候也有可能出現這樣的狀況。解決方法類似。
分支管理#
使用 git branch 命令和 git checkout 命令創建分支、切換分支。命令的使用不再贅述，參考 git branch 命令 | 菜鳥教程 以及其他相關資料。
Git 分支的命名和功能：
- master/main（主分支，永遠是可用的穩定版本，不能直接在該分支上開發）
- develop（開發主分支，所有新功能以這個分支來創建自己的開發分支，該分支只做合併操作，不能直接在該分支上進行開發）
- feature-xxx（功能開發分支，在 develop 上創建分支，以自己開發功能模塊命名，功能測試正常後合併到 develop 分支）
- feature-xxx-fix（功能 bug 修復分支，feature 分支合併之後發現 bug，在 develop 上創建分支進行修復，之後合併回 develop 分支）
- hotfix-xxx（緊急 bug 修改分支，在 master 分支上創建，修復完成後合併到 master）
- bugfix/* 分支 （短期從 develop 創建）
- release/* 分支（短期從 develop 創建）
各分支的關係，可以參考下圖。
如上所述多人協作開發的專案，常以多分支並行的方式推進。不允許直接 push 到 main/master 分支和 develop 分支上。
為什麼不能直接 push 到 main/master 分支？ 因為 main/master 分支應當是一個穩定的分支。沒有惡性 bug，幾乎隨時可以使用，基本實現預定功能。
當然，許多朋友可能也曾經使用過 git 管理個人小型專案，這時候當然沒有那麼多講究。
使用 Pull Request (PR) 合併代碼 PR 的方法可以避免直接 push 造成不可預期的結果，能夠支持代碼審查，還可以引入自動化工具輔助等等。
具體可以參考 為什麼不能直接 push 到 master 分支 | Weitang Li's blog
如何發起 PR 參考下圖，根據頁面提示操作即可。
必读的開發流程#
幾個重要的點，必須強調一下
開發前務必執行 pull 操作#
每一次開發前都要 pull❗解決可能存在的衝突，並更新代碼。也避免重複工作
不使用 main (master) 分支和 develop (dev) 分支開發#
我們禁止直接 push 到 main 分支和 develop 分支上。新建對應的 feature (feat) 功能分支開發是最優解。
分支 feature-xxx 的命名可以根據要開發的功能而定。然後使用 PR 來合併代碼。
PR 的方向： 從 feat 等分支提交到 dev 分支，然後由 dev 分支提交到 main 分支，不要越級提交
若違反此步驟，造成分支混亂，後果絕對是地獄級別難度
代碼提交以及 PR 寫清楚 commit message#
告訴隊友你幹了什麼❗節省大家的時間。具體可見上文。
分支合併需要 review#
通常 PR 不會直接通過，可能需要同組其他成員進行代碼復查，然後才能被允許合併。關注 PR 界面的評論區，可以及時收到反饋和修改建議。
不確定就不要操作，在群裡問#
比如產生了代碼衝突，有時候並不是別人的代碼不對；
又比如可能產生了沒有見過的問題等等……
搜索解決方案是一方面，一定要和其他隊員說一聲，不要閉門造車😅
Good Luck#
祝好