摘要:GIT -Merge
參考連結：
[git][merge]實際操作,合併與他人做的專案
http://italwaysrainonme.blogspot.tw/2012/12/gitmerge_20.html
Git flow 開發流程
http://ihower.tw/blog/archives/5140
A successful Git branching model
http://nvie.com/posts/a-successful-git-branching-model/
[Git] 版本控制: 如何使用標籤(Tag)
http://blog.wu-boy.com/2010/11/git-%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B6-%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8%E6%A8%99%E7%B1%A4tag/
第一步，切到你的主要的branch(正在開發的最新版，或Developer，或master)，
第二步，Merge 開發的 branch 至 主要的branch
git merge feature_branch
如果有衝突的話，會告訴你一些衝突的地方
CONFLICT (content): Merge conflict in <file_name>
Automatic merge failed; fix conflicts and then commit the result.
等所有衝突修正後，再commit, 然後再push上去，這時，就會看到兩個branch兩在一個交點上。
若沒有衝突則出現
Merge made by the `recursive` strategy.
..略
xxx files changed , xxx insertions(+), xxx deletions(-)
對版本Tag
git tag -a v1.x.x -m 'descript'
git push origin --tags
在上面這張圖顯示
三個主要的branch ：master、 release、develop
develop 為目前正在開發
release 為發佈給使用者測試或內部人員測試，
master 則為上架時的版本。
所以只要一上架，就要將develop的branch merge 回 master 使master擁有最新的資訊。
而develop可能會有多個人開發每個人開發不同的版本，則將develop的版本，另外開出不同的feture branch去開發部分功能，
等開發完，再將feture branch merge 回 develop ，develop 再merge 回release，等release測試完後，無誤，則再merge回master
若在release有發生錯誤，由release版本修正後，merge 回develop，再merge 至master
若在master發生急緊需要上架的版本，則會開新的branch hotfiex ，再將hotfiex merge回master，及develop
每次發佈版本上架時，就會加上一個Tag
master，看來就沒有要在這主線上開發什麼，開發都branch 出去 到develop。
有了這種版控方式，讓多個版本同時進行時，變的清鬆許多，也清楚要怎麼去做版控的方式。
因為我有四個版本，一個是現在上架版，一個是上架後，又發生緊急修正部分功能的版本，又一個是，開發新功能的版本，再一種是開發新功能後，又大修的功能。
因為緊急修正版本，又是在開發新功能後才出現的，讓我為了這緊急修正的版本，我就需要將這程式碼一個貼到開發新功能的版本，，再貼到大修的版本。
發現這樣真的很累，
但有了merge的功能的話，
我就可以，新功能版本 merge 緊急修正部分，大修merge 新功能版本。就將緊急功能，merge至大修裡了。
這張圖，會讓開發者，會更有條有理的去做版本控制。不必再多個版本去做相同程式的修改。（現在才學會merge，真有點晚，浪費許多時間改同樣的程式碼）
