現在，大部分項目都是用 git 來管理代碼的，但當項目變大、多人協作時，git 的使用就變得複雜了，這時就需要在 git 使用的流程上來思考如何更優的使用 git。
對於大部分 web 項目而言，並不像軟件、APP 項目一樣有版本的劃分，而是不斷的更新、迭代，這就使得 web 項目的 git 使用要複雜一些，需要管理好哪些是正在開發的代碼、哪些是提交測試的代碼、哪些是已經上線的代碼、多人共同開發時如何避免代碼衝突與線上新代碼被舊代碼覆蓋等等。
小編整理了一些java進階學習資料和麪試題，需要資料的請加JAVA高階學習Q羣：664389243 這是小編創建的java高階學習交流羣，加羣一起交流學習深造。羣裏也有小編整理的2019年最新最全的java高階學習資料！
- 一個分支
如果項目比較小，不頻繁更新時，可以只用 master 一個分支。
使用流程：
交代碼到本地 master 分支，並推送到遠程 master 分支
持續集成構建或本地構建，然後上傳到服務器
上傳到服務器有兩種方式：
持續集成構建，然後同步到服務器
本地構建，然後上傳到服務器（爲了簡潔清晰，後面的圖例中會隱藏這種方式）
- 開發分支與個人分支
如果項目稍大些，頻繁更新時，就需要另外一個開發分支：
master：主分支，對應線上代碼
dev：開發分支，對應開發代碼
使用流程：
提交代碼到本地 dev 分支
在需要構建項目時 merge 到本地 master 分支，並推送到遠程 master 分支
持續集成構建，然後同步到服務器
如果是多人蔘與的項目，就需要個人開發分支了：
master：主分支，對應線上代碼
man1：個人 man1 開發分支
man2：個人 man2 開發分支
使用流程：
提交代碼到本地 man1 分支（以 man1 個人爲例）
在需要構建項目時 merge 到本地 master 分支，並推送到遠程 master 分支（有可能需要先 pull 遠程的代碼）
持續集成構建，然後同步到服務器
在適當的時候，每一個個人分支（如 man1, man2）都需要 pull 一下 master 分支，以保證自己本地的代碼的版本不會低於服務器。
- 多個服務器環境
如果項目比較大，並且對應多個服務器環境（測試環境、產品環境）：
master：主分支
prod：產品分支，對應產品服務器環境
test：測試分支，對應測試服務器環境
dev：開發分支
使用流程：
構建測試環境：
提交代碼到本地 dev 分支
在需要構建項目時 merge 到本地 test 分支，並推送到遠程 test 分支
持續集成構建，然後同步到測試服務器
構建產品環境可以由遠程的 test 分支 merge 到遠程 prod 分支進行持續集成構建，也可由本地 dev 或 test 分支 merge 到本地 prod 分支，並推送到遠程 prod 分支進行持續集成構建。
如果是多人蔘與的項目，就需要個人開發分支了：
master：主分支
prod：產品分支，對應產品服務器環境
test：測試分支，對應測試服務器環境
man1：個人 man1 開發分支
man2：個人 man2 開發分支
使用流程：
構建測試環境：
提交代碼到本地 man1 分支（以 man1 個人爲例）
在需要構建項目時 merge 到本地 test 分支，並推送到遠程 test 分支（有可能需要先 pull 遠程的代碼）
持續集成構建，然後同步到測試服務器
構建產品環境可以由遠程的 test 分支 merge 到遠程 prod 分支進行持續集成構建，也可由本地 man1 或 test 分支 merge 到本地 prod 分支，並推送到遠程 prod 分支進行持續集成構建。
在適當的時候，每一個個人分支（如 man1, man2）都需要 pull 一下 prod 分支（如有需要，也可以 pull test 分支），以保證自己本地的代碼的版本不會低於服務器。
- 多個需求同時開發
有時候會有多個需求同時開發，並且相互獨立，爲了不影響每個需求的測試與上線，需要爲每個需求創建一個分支。
master：主分支
prod：產品分支，對應產品服務器環境
test：測試分支，對應測試服務器環境
man1：個人 man1 開發分支
man2：個人 man2 開發分支
task1：需求 task1 開發分支
task2：需求 task2 開發分支
使用流程：
構建測試環境與之前的步驟一致，但構建產品環境時，爲了保證各個需求不相互影響，一般由本地直接合併到 prod 分支：
本地 task1 分支 merge 到本地 prod 分支，並推送到遠程 prod 分支進行持續集成構建
每一個個人分支（如 man1, man2）都需要 pull 一下 prod 分支，以保證自己本地的代碼的版本不會低於服務器
最後刪除 task1 分支
- 多人協作開發修改公共文件
因爲不同分支修改同一個文件而導致的文件衝突是多人協作開發中比較常見的問題之一，避免這種問題的思路主要有以下的幾種：
在代碼層面，儘量避免多個成員都會改動的文件，儘量將代碼分解到每個人只負責自己的那塊代碼，不需要去改別人的代碼
在工程層面，儘量減少公共文件，儘量每個文件只由一個人負責
在 git 層面，如果有必要，可以單獨建一個分支，用於更新某些公共文件，並及時的更新到其他分支
- 其他分支
有一些常用的分支，可能我們會用到：
bug 分支：用於緊急修復產品環境的 bug
- 根據情況調整、簡化流程
上面的圖例只有測試服務器和產品服務器，更多服務器類型的工作流程是類似的；圖例也只有 man1 和 man2 兩個個人分支，更多個人分支的工作流程也是類似的。
上面的圖例主要用於以下特點的項目（需要把整個項目打包成一個整體）：
單頁面 web 前端應用，整個項目只有一個 html 文件，頁面之間的切換由本地路由控制，每次更新到服務器都需要打包所有頁面
Java、Go 等後端應用，每次都需要打包成一個整體，可能是一個文件，或者一批文件（不打包成一個整體的方式除外，比如分散 java class 文件）
使用持續集成構建的方式更新代碼到服務器
這樣做主要是爲了避免一些問題：
線上新代碼被舊代碼覆蓋：多人同時開發項目，都需要更新到測試機，如果不是統一 push 到 test 分支做持續集成構建，很難保證線上新代碼不會被舊代碼覆蓋
未測試的代碼被更新到產品環境：這個問題也需要注意，因爲這個問題並不能從流程上完全杜絕，需要各位在開發中留意
對於像下面這種特點的項目，可以根據情況調整、簡化流程：
多頁面 web 前端應用，把某一個頁面更新到服務器並不影響其他頁面
NodeJs、PHP、Python 等後端應用，只上傳自己更新的文件，而不影響服務器上其他文件（把所有代碼打包成一個整體的方式除外）
使用本地構建的方式更新代碼到服務器
比如：
master：主分支
man1：個人 man1 開發分支
man2：個人 man2 開發分支
task1：需求 task1 開發分支
task2：需求 task2 開發分支
使用流程：
如果多個需求沒有衝突，可以同時在 man1 個人分支上開發，並根據需要上傳到不同的服務器。
如果多個需求有衝突，可以每個需求都新建一個分支，如上圖所示：
提交代碼到本地 task1 分支（以 task1 個人爲例）
根據需要上傳到不同的服務器
如果代碼通過產品環境後，更新到每個個人分支，並刪除 task1 分支
這樣子，就簡單很多了
小編整理了一些java進階學習資料和麪試題，需要資料的請加JAVA高階學習Q羣：664389243 這是小編創建的java高階學習交流羣，加羣一起交流學習深造。羣裏也有小編整理的2019年最新最全的java高階學習資料！