# Git Branch & Merge

簡單認識下 Branch & Merge

從字面意思來看，Merge是用於合併Branch，那為何需要再建立其他的branch？不能只用一條branch作業嗎？

我們以情境的方式，帶入假設來看

假設今天系統已上線數個月，且趨向穩定的狀況，此時我們可以將穩定版本的程式碼視為 master branch 或 main branch

當接收到新的Ａ需求時，我們會以穩定版本的master/main branch為基底，進行Ａ功能開發

後續系統因業務日漸龐大，同時接收到新的B、C、D需求。

但需要避免因開發而產生不必要的Bug，因此每個需求仍需以穩定版本的master/main branch為基底進行開發。

若維持單一branch的方式開發，此時總開發時程會拉的很長，造成整體開發效率低下。
</br>

此時，如果我們讓每個新需求都擁有一條branch。便可依功能分派給不同的工程師，同時開發B、C、D需求，加速整個團隊的開發效率。

當B、C、D需求開發完成時，開發團隊會需要將三條branch整合回master/main branch，再進行B、C、D功能的上線

其流程看似合理，實質卻存在著風險。

三個branch可能會因為功能不同的關係，在同個程式檔案中，有不同的流程或程式邏輯，一次強制合併三個branch過於複雜，並且可能會造成其他不可預期的系統錯誤。

合併分支時，相同程式檔案有不同的程式碼，稱之為『衝突』
</br>

如果以前面的方式稍加改良，在保持使用穩定版本的前提下，可以保留原先的master/main branch，為每個新需求都另開一條新的branch。

並且在B、C、D任一需求開發完成時，一次只整合一項需求回master/main branch

可隨時保有一版可正常穩定運行的版本。
</br>

# Git指令操作分支建立與合併
以下示範從分支建立、異動提交到最終的分支合併整個流程，如何以git指令進行操作

* `git branch -v`
檢視目前位在哪個分支，以及還有哪些其他分支(*為當前位置)

* `git branch [branchName]`
以目前分支為基底，新增branch

* `git checkout [branchName]`
切換目前位置至指定的branch

* 新增或修改程式

* `git add [fileName]`
將異動的檔案新增至暫存區(Staging Area)

* `git commit -m [message]`
將暫存區的檔案提交至本機儲存庫(Local Repository)

* `git remote -v`
檢視遠端除存庫(Remote Repository)於本機的名稱
[remoteName] [remoteUrl]

* `git push [remoteName] [branchName]`
將本機儲存庫(Local Repository)推送至遠端儲存庫(Remote Repository)

* `git checkout`切換回main/master branch準備進行merge

### 無衝突的merge
* `git merge [branchName]`
將指定(dev)branch合併至當前(main/master)branch

* merge成功，同樣推送至遠端儲存庫(Remote Repository)

### 有衝突的merge
* `git merge [branchName]`

* `git status`檢視目前的檔案異動狀態
此次修改了testFile.txt

* 檢視testFile.txt衝突內容
等號向上是目前分支(main/master)的testFile.txt內容
等號向下是dev分支的testFile.txt內容

* 確認testFile.txt最終需保留的內容，並重新提交testFile.txt

成功解決main/master與dev的衝突

# 總結
branch的使用方式可以參考Git Flow、GitHub Flow 或 GitLab Flow等流程所定義的規範。

通常會以其中一種為基底，再根據團隊習慣或專案需求進行客製化調整。

團隊成員彼此事先溝通好，有相同共識的flow即可。

</br>

>[!Tip]
文章內容皆為個人整理的觀點，以及整理後的個人想法，如內容有錯誤或疑慮的部分，歡迎提出討論，收到後會盡快修正！