前言

沒(méi)有什么規(guī)則是完全正確的，但如果沒(méi)有大家統(tǒng)一認(rèn)可的規(guī)則，各自為戰(zhàn)，事情將會(huì)變成一團(tuán)糟。

代碼倉(cāng)庫(kù)與分支管理

SVN分支管理

很多創(chuàng)業(yè)公司的代碼倉(cāng)庫(kù)是使用的SVN，集中式代碼倉(cāng)庫(kù)，我們最初用的也是，很古老的工具，我知道。
使用SVN，有兩種開(kāi)發(fā)模式，

1. 主干開(kāi)發(fā)
   所有研發(fā)開(kāi)發(fā)不拉新分支，在本地開(kāi)發(fā)完一部分后commit到master，有沖突及時(shí)解決。理念是因?yàn)榻鉀Q大沖突很痛苦，所以要經(jīng)常解決小沖突，永遠(yuǎn)保證master代碼是可發(fā)布的狀態(tài)，小步迭代，快速交付。事實(shí)上這個(gè)理念相當(dāng)理想，基本不可能實(shí)現(xiàn)。
   這個(gè)是建立在每個(gè)研發(fā)的代碼質(zhì)量很高，并且可以自覺(jué)且完整地測(cè)試，以保證0 bug commit到master，或有全面的回歸測(cè)試，才能保證master代碼永遠(yuǎn)是可發(fā)布狀態(tài)。
   在初創(chuàng)公司，如果你用SVN，千萬(wàn)不要作這個(gè)死。如果你這么用的話，經(jīng)常會(huì)發(fā)現(xiàn)，master代碼都是半成品或充滿bug，這時(shí)候如果有高優(yōu)需求或hotfix，只能各種翻svn log，退回分支開(kāi)發(fā)。

2. 分支開(kāi)發(fā)
   分支開(kāi)發(fā)會(huì)更常見(jiàn)些，每次新迭代開(kāi)始，或有新功能開(kāi)發(fā)時(shí)，都從master上拉出一個(gè)開(kāi)發(fā)分支，相當(dāng)于全量拷貝一份代碼到新分支上。
   在新分支上進(jìn)行開(kāi)發(fā)，開(kāi)發(fā)完之后，可以直接將這個(gè)分支發(fā)布到生產(chǎn)環(huán)境，也可以將代碼合并到Master，然后發(fā)布master到生產(chǎn)環(huán)境。
   當(dāng)然，我們強(qiáng)烈建議先把分支代碼合并到master，再發(fā)布master代碼，通過(guò)流程強(qiáng)制約束master代碼永遠(yuǎn)是最新的。如果有多個(gè)分支并行開(kāi)發(fā)，合并代碼的時(shí)候可能會(huì)比較痛苦，要去解決沖突。
   基本這么做的話，也不會(huì)有什么大問(wèn)題。除了開(kāi)分支的時(shí)候全量拷貝比較蛋疼。

Git分支管理

Git，是大神linus繼linux內(nèi)核之后的又一神級(jí)的產(chǎn)品。在理念上領(lǐng)先svn一個(gè)時(shí)代。詳細(xì)可以從網(wǎng)上看svn，git的對(duì)比。對(duì)我而言，git和svn的不同，主要表現(xiàn)在

1. svn是集中式的，只有一個(gè)中心。而git是分布式的，每個(gè)人都可以有全量的代碼。從命令上就可以體現(xiàn)出來(lái)，svn checkout V.S. git clone
2. svn創(chuàng)建新分支是從master拷貝全量的文件到新branch，git是增量的。所以同時(shí)開(kāi)10個(gè)分支，svn的源文件會(huì)變成10份，而git不會(huì)。

實(shí)際使用中，可以采用git-flow的方式，將各類branch細(xì)化使用。主要分這么幾類分支

1. master
2. release
3. dev-branch
4. hotfix

詳情可以參考阮一峰-Git 工作流程，不展開(kāi)了。

生產(chǎn)環(huán)境的版本管理

工程的運(yùn)維規(guī)范化

統(tǒng)一目錄結(jié)構(gòu)

統(tǒng)一啟?？刂颇_本

統(tǒng)一maven倉(cāng)庫(kù)

多環(huán)境下多套配置文件

統(tǒng)一編譯腳本