ack 效率 使用 普通 代碼管理 otf 今天 com 建立

之前項目用的都是SVN進行代碼管理的，最新的兩個項目開始用git了。非常早之前就開始接觸git。可是一直沒有正規的使用過，所以對git的命令並非非常熟悉，基本上的命令都是使用諸如clone、checkout、add、commit之類的命令。沒有使用過創建分支（branch）和打tag之類的操作，眼下項目中常常出現一種情況：項目開始的時候我們都在master分支上開發，然後等到一個階段完畢之後我們會公布這個版本號，然後再創建一個develop分支，接著在develop分支上開發。然後對master分支公布，打tag。接著再繼續在develop分支上開發，可是在開發過程中之前公布的版本號可能出現一些bug。這時候須要緊急的修復。
在當前的項目中，我逐漸開始接觸到了項目中的代碼管理。我們普通情況是保持三個分支：master分支。release分支和develop分支，master分支上的代碼始終是穩定的，也就是當前最新公布的版本號，release分支上的代碼是給QA部署使用的，開發者不能改動。開發僅僅能夠向develop分支上提交代碼，然後自測完畢之後再將develop上的代碼merge到release分支上通知QA部署QA環境而且測試，當QA測試完畢之後能夠公布的時候再將release分支上的代碼merge到master，之後能夠將master分支上的代碼構建。公布。再對當前公布的版本號打tag。

這種一套流程中，當出現上面的問題時須要基於之前公布的版本號進行緊急修復。這是就在master上拉取一個分支，由於master上的代碼就是當前公布版本號的代碼，比如稱為XXX-hotfix分支，然後在這個分支上做修復。修復完畢之後再將該分支合並到release中由QA部署測試。成功之後還須要將這個版本號再合並到master上和develop上。然後再對master上的分支打tag，構建公布。
所以在當前的代碼管理中通常會存在3個分支。最多存在一個hotfix分支。master分支上的代碼總是當前上線版本號的代碼。開發僅僅可以在develop分支上提交代碼，所以沖突基本上都是在提交develop時候產生的，develop上合並到release和master上的時候基本上都可以自己主動合並的，當然假設存在多個開發版本號的情況須要再進行討論。

曾經項目中沒有這麽規範的流程，基本上也都是一個人開發，然後提交完畢之後就交給QA測試了，沒考慮到這些規範，當然隨著規範的建立也多也一些繁瑣的交互。可是這樣長久下來還是效率比較高的。

最後今天在使用git的時候不小心出現的一個問題。當我在hotfix分支上開發測試完畢之後須要merge到develop分支和master分支上。當前我的git bash處於develop分支，我本來想pull一下最新的版本號，卻寫成了git pull origin hotfix，這樣子就把hotfix分支上的內容合並到了develop上。事實上這個操作和merge幾乎相同，然後我運行git push origin develop之後發現了develop上的最後一次提交的message是這種：Merge branch ‘hive-hotfix‘ of https://xxx.git.com.cn/git/xxx/xxx into develop。

這個commit的message應該是git自己主動生成的，這就意味著當我把另外一個分支pull到當前的分支上之後運行了代碼合並操作而且將本次合並之後的內容commit了。然後吸取了教訓。切換到master分支，再次merge hive-hotfix分支，然後再push origin master，查看master上的commit記錄發如今hive-hotfix中的提交記錄也都提交上去了。 所以在merge的時候不不過代碼的merge，還是提交每個的commit，可是直接運行pull的時候則不會。因此下次須要警惕，一定不能在一個分支上pull另外一個分支的內容。而是用merge！

最近項目中代碼管理學習