原文鏈接：https://www.cnblogs.com/javabg/p/8567790.html
工作中多人使用版本控制軟件協作開發，常見的應用場景歸納如下：
假設小組中有兩個人，組長小張，組員小袁
- 場景一：小張創建項目並提交到遠程Git倉庫
- 場景二：小袁從遠程Git倉庫上獲取項目源碼
- 場景三：小袁修改了部分源碼，提交到遠程倉庫
- 場景四：小張從遠程倉庫獲取小袁的提交
- 場景五：小袁接受了一個新功能的任務，創建了一個分支並在分支上開發
- 場景六：小袁把分支提交到遠程Git倉庫
- 場景七：小張獲取小袁提交的分支
- 場景八：小張把分支合並到主干
場景一：小張創建項目並提交到遠程Git倉庫
創建好項目，選擇VCS - > Import into Version Control -> Create Git Repository
接下來指定本地倉庫的位置，按個人習慣指定即可，例如這里選擇了項目源代碼同目錄
點擊OK后創建完成本地倉庫，注意，這里僅僅是本地的。下面把項目源碼添加到本地倉庫。
下圖是Git與提交有關的三個命令對應的操作：
- Add命令是把文件從IDE的工作目錄添加到本地倉庫的stage區，
- Commit命令把stage區的暫存文件提交到當前分支的倉庫，並清空stage區。
- Push命令把本地倉庫的提交同步到遠程倉庫。
IDEA中對操作做了一定的簡化，Commit和Push可以在一步中完成。
具體操作，在項目上點擊右鍵，選擇Git菜單
因為是第一次提交，Push前需要指定遠程倉庫的地址。如下圖，點擊Define remote后，在彈出的窗口中輸入遠程倉庫地址。
場景二：小袁從遠程Git倉庫上獲取項目源碼
即克隆項目，操作如下：
輸入小張Push時填寫的遠程倉庫地址
接下來按向導操作，即可把項目從遠程倉庫克隆到本地倉庫和IDE工作區。
場景三：小袁修改了部分源碼，提交到遠程倉庫
這個操作和首次提交的流程基本一致，分別是 Add -> Commit -> Push。請參考場景一
場景四：小張從遠程倉庫獲取小袁的提交
- Fetch是從遠程倉庫下載文件到本地的origin/master，然后可以手動對比修改決定是否合並到本地的master庫。
- Pull則是直接下載並合並。
場景五：小袁接受了一個新功能的任務，創建了一個分支並在分支上開發
建分支也是一個常用的操作，例如臨時修改bug、開發不確定是否加入的功能等，都可以創建一個分支，再等待合適的時機合並到主干。
創建流程如下：
選擇New Branch並輸入一個分支的名稱
創建完成后注意IDEA的右下角，如下圖，Git: wangpangzi_branch表示已經自動切換到wangpangzi_branch分支，當前工作在這個分支上。
點擊后彈出一個小窗口，在Local Branches中有其他可用的本地分支選項，點擊后選擇Checkout即可切換當前工作的分支(見場景7操作切換其他分支)。
如下圖，點擊Checkout
注意，這里創建的分支僅僅在本地倉庫，如果想讓組長小張獲取到這個分支，還需要提交到遠程倉庫。
場景六：小袁把分支提交到遠程Git倉庫
切換到新建的分支，使用Push功能
場景七：小張獲取小袁提交的分支
使用Pull功能打開更新窗口，點擊Remote欄后面的刷新按鈕，會在Branches to merge欄中刷新出新的分支。
這里並不想做合並，所以不要選中任何分支，直接點擊Pull按鈕完成操作。
更新后，再點擊右下角，可以看到在Remote Branches區已經有了新的分支，點擊后在彈出的子菜單中選擇Checkout as new local branch，在本地倉庫中創建該分支。完成后在Local Branches區也會出現該分支的選項，可以按上面的方法，點擊后選擇Checkout切換。
場景八：小張把分支合並到主干
新功能開發完成，體驗很好，項目組決定把該功能合並到主干上。
切換到master分支，選擇Merge Changes
選擇要合並的分支，點擊Merge完成
團隊項目Git分支管理規范
分支管理
創建項目時（一般是服務型項目，工具型或輔助型項目可以簡單一些），會針對不同環境創建三個常設分支：
- develop：開發環境的穩定分支，公共開發環境基於該分支構建。
- pre-release：測試環境的穩定分支，測試環境基於該分支構建。
- master：生產環境的穩定分支，生產環境基於該分支構建。僅用來發布新版本，除了從pre-release或生產環境Bug修復分支進行merge，不接受任何其它修改
平時開發工作中，會根據需要由開發人員創建兩類臨時分支：
- 功能（feature）分支：為了開發某個特定功能，從develop分支上面分出來的。開發完成后，要merge到develop分支。功能分支的命名，可以采用feature-*的形式命名(*為任務單號)
- Bug修復（fixbug）分支：為了修復某個bug，從常設分支上面分出來的。修復完成后，再merge到對應的分支。Bug修復分支的命名，可以采用fixbug-*的形式命名（*為bug單號）
流程規范
- 從develop分支切出一個新分支，根據是功能還是bug，命名為feature-* 或 fixbug-*。
- 開發者完成開發，提交分支到遠程倉庫。
- 開發者發起merge請求（可在gitlab頁面“New merge request”），將新分支請求merge到develop分支，並提醒code reviewer進行review
- code reviewer對代碼review之后，若無問題，則接受merge請求，新分支merge到develop分支，同時可刪除新建分支；若有問題，則不能進行merge，可close該請求，同時通知開發者在新分支上進行相應調整。調整完后提交代碼重復review流程。
- 轉測時，直接從當前develop分支merge到pre-release分支，重新構建測試環境完成轉測。
- 測試完成后，從pre-release分支merge到master分支，基於master分支構建生產環境完成上線。並對master分支打tag，tag名可為v1.0.0_2019032115（即版本號_上線時間）
