一．提交之前先更新

1.         SVN更新的原則是要隨時(shí)更新，隨時(shí)提交。當(dāng)完成了一個(gè)小功能，能夠通過編譯并且自己測(cè)試之后，謹(jǐn)慎地提交。

2.         如果在修改的期間別人也更改了svn的對(duì)應(yīng)文件，那么commit就可能會(huì)失敗。如果別人和自 己更改的是同一個(gè)文件，那么update時(shí)會(huì)自動(dòng)進(jìn)行合并，如果修改的是同一行，那么合并時(shí)會(huì)產(chǎn)生沖突，這種情況就需要同之前的開發(fā)人員聯(lián)系，兩個(gè)人一起協(xié)商解決沖突，解決沖突之后，需要兩人一起測(cè)試保證解決沖突之后，程序不會(huì)影響其他功能。

3.         在更新時(shí)注意所更新文件的列表，如果提交過程中產(chǎn)生了更新，則也是需要重新編譯并且完成自己的一些必要測(cè)試，再進(jìn)行提交。這樣既能了解別人修改了哪些文件，同時(shí)也能避免SVN合并錯(cuò)誤導(dǎo)致代碼有錯(cuò)

二．保持原子性的提交

每次提交的間歇盡可能地短，以幾個(gè)小時(shí)的開發(fā)工作為宜。例如在更改UI界面的時(shí)候，可以每完成一個(gè)UI界面的修改或者設(shè)計(jì)，就提交一次。在開發(fā)功能模塊的時(shí)候，可以每完成一個(gè)小細(xì)節(jié)功能的測(cè)試，就提交一次，在修改bug的時(shí)候，每修改掉一個(gè)bug并且確認(rèn)修改了這個(gè)bug，也就提交一次。我們提倡多提交，也就能多為代碼添加上保險(xiǎn)。

三．提交時(shí)注意不要提交本地自動(dòng)生成的文件

一般配置管理員都會(huì)將項(xiàng)目中一些自動(dòng)生成的文件或者與本地配置環(huán)境有關(guān)的文件屏蔽提交（例如eclipse中的.classpath文件等）。如果項(xiàng)目中沒有進(jìn)行這方面的配置來強(qiáng)行禁止提交這樣的文件，請(qǐng)自覺不要提交這樣的文件。提交了這樣的文件后，別人在更新后就可能與本地的環(huán)境沖突從而影響大家的工作。

四．不要提交不能通過編譯的代碼

代碼在提交之前，首先要確認(rèn)自己能夠在本地編譯。如果在代碼中使用了第三方類庫(kù)，要考慮到項(xiàng)目組成員中有些成員可能沒有安裝相應(yīng)的第三方類庫(kù)。項(xiàng)目經(jīng)理在準(zhǔn)備項(xiàng)目工作區(qū)域的時(shí)候，需要考慮到這樣的情況，確保開發(fā)小組成員在簽出代碼之后能夠在統(tǒng)一的環(huán)境中進(jìn)行編譯。

五．不要提交自己不明白的代碼

代碼在提交入SVN之后，你的代碼將被項(xiàng)目成員所分享。如果提交了你不明白的代碼，你看不懂，別人也看不懂，如果在以后出現(xiàn)了問題將會(huì)成為項(xiàng)目質(zhì)量的隱患。因此在引入任何第三方代碼之前，確保你對(duì)這個(gè)代碼有一個(gè)很清晰的了解。

六．提前協(xié)調(diào)好項(xiàng)目組成員的工作計(jì)劃

項(xiàng)目經(jīng)理應(yīng)該合理分配工作計(jì)劃。每個(gè)成員在準(zhǔn)備開始進(jìn)行某項(xiàng)功能的修改之前，如果有可能，先跟工作小組的成員談?wù)勛约旱男薷挠?jì)劃，讓大家都能了解你的思想，了解你即將對(duì)軟件作出的修改，這樣能盡可能的減少在開發(fā)過程中可能出現(xiàn)的沖突，提高開發(fā)效率。同時(shí)你也能夠在和成員的交流中發(fā)現(xiàn)自己之前設(shè)計(jì)的不足，完善你的設(shè)計(jì)。

七．對(duì)提交的信息采用明晰的標(biāo)注

在一個(gè)項(xiàng)目組中使用SVN，如果提交空的標(biāo)注或者不確切的標(biāo)注將會(huì)讓項(xiàng)目組中其他的成員感到很無奈，項(xiàng)目經(jīng)理無法很清晰的掌握工作進(jìn)度，無法清晰的把握此次提交的概要信息。在發(fā)現(xiàn)錯(cuò)誤后也無法準(zhǔn)確的定位引起錯(cuò)誤的文件。所以，在提交工作時(shí)，要填寫明晰的標(biāo)注，能夠概要的描述所提交文件的信息，讓項(xiàng)目組其他成員在看到標(biāo)注后不用詳細(xì)看代碼就能了解你所做的修改。

八．慎用鎖定功能

I would like to point your attention to some best practices that I recommend when working in a team.

1. Don’t use versioning like it were a backup tool.

   I’ve heard this question too often: “Have you put your code safely on SVN?”. That’s a bad question. Storing code to an SVN server is not meant for safety, i.e. for fear of losing it. You are talking about something else, and that’s called backup. Take Darcs, a not so popular versioning system. It can start without a server, and you can just run it locally on your machine without launching any daemon whatsoever. A faulty hard drive can still make you lose all your work, of course. That’s why you have to do backups, of course, but they don’t have anything to do with versioning. Hence, committing to the repository once a day, before taking off home, e.g., is not an acceptable practice, especially if you work in a team. Doing that would be like making a daily backup. An SVN commit, instead, has to have a meaning of some sort, not just “Ok, let’s store to the SVN server the work of today”. Moreover, sometimes, if the schedule is tough and the cooperation is tight, you need to commit very often so your peer will keep up with you all the time, and not just find out, at evening, that he’s got dozens conflicts after checking out your code.

2. Commit as soon as your changes makes a logical unit.

   How often should you commit? Theres no such thing as committing too often, or too rarely. You should commit each time your changes represent a logical unit, i.e. something that makes sense. Usually that happens because you’re following a plan, when coding (because you are, aren’t you?). So, you find out a bug in the trunk, plan a strategy about how to fix it, fix it, and then commit. This makes sense because that’s a commit that fixes a bug. So that revision X is buggy, while revision X+1 is not. Don’t be shy about committing too often. Should you just find an insignificant typo in a debug string, or in a comment, don’t be afraid of committing just to fix that. Nobody will be mad at you for being precise. Consider the extreme situation in which, after months and months, you may want to remember “What was the revision where I fixed that typo in that debug string?”. If you dedicated one signle commit for the actual finite logical unit of correcting the typo, you can just scroll back your changelog and find it. But what often happens, is that people will be doing something else, and, while doing that something else, will notice the type, and correct it, and basically merge that correction with the rest of the commit, making that thing losing visibility. To make it simple: your SVN comments shouldn’t explain that you did more than one thing. If your SVN comment looks like “Fixing bugs #1234 and #1235″ or “Fixing bug #4321 and correcting typo in debug sting” then you should’ve used two commits.

3. Be precise and exhaustive in your commit comments.

   The second most annoying thing ever is committing with blank comments. If you’re working in a team, your peer developers will be frustrated about it and possibly mad at you, or will label you in a bad way; possibly publicly humiliate you. If you’re working alone, you will experience what you’re hypothetical development companions would have: frustration in not being able to easily track down what a certain commit did. Comments in commits are important. Please be precise and explain in detail everything you did. In the optimal case, I shouldn’t need to read your code.

4. Never ever break the trunk.

   This is probably the most annoying thing when dealing with people who can’t use versioning. Breaking the trunk is an habit that will quickly earn you the hatred of your colleagues. Think about it: if you commit a patch that breaks the trunk, and then I check it out, what am I going to do? The project won’t build so I either have to fix it, or come to your desk and complain to you. In both cases I’m wasting some time. And consider the first case again: what should I do after fixing your broken code? Commit it? Sending you a diff? If I’ll commit, chances are that you’ll have conflicts when you checkout, and you’ll have to waste time in resolving them. Maybe sending you a patch would be the best way, but still it’s a waste of time for the both of us. So the thing is: before committing, ALWAYS double check! Make a clean build and make sure that it builds. And don’t forget to add files! It’s a very common mistake: committing good code, but forgetting to add a file. You won’t realize, because the thing builds, but when I’ll checkout, I’ll have troubles, because of missing file(s). If you’re using Darcs, just make a “darcs get” in a new directory, and then build.

5. Branch only if needed.

   There are some ways to handle branches, but here’s my favorite. The most of the work should happen in the trunk, which is always sane, as stated by the previous practice, and the patches should always be small, so that they can be reviewed very easily. If you find yourself in the situation of needing to write a large patch, then you should branch it. In that way you can have small patches that will break your branch over the time, but they can be easily reviewed. After the process is completed, i.e. you’ve achieved your goal of fixing a bug or implementing a new feature, you can test the branch thoroughly, and then merge it to the trunk.

并行軟件開發(fā)是企業(yè)級(jí)環(huán)境下軟件開發(fā)的一種不可避免的模式，這種開發(fā)模式可以說是任何大中型軟件產(chǎn)品和項(xiàng)目所必需的。然而，并行開發(fā)在為我們的開發(fā)效率提高保證的同時(shí)，也會(huì)給我們的開發(fā)管理帶來諸多問題：

* 什么時(shí)候進(jìn)行分支？
* 什么時(shí)候進(jìn)行合并？
* 如何選擇有效的分支策略？
* 如何保證不同分支上的代碼同步問題？
* 如果建立對(duì)分支訪問控制的授權(quán)機(jī)制？
* 如何避免頻繁的合并沖突？
* 如何處理被復(fù)用的代碼？
* ……

可以說并行開發(fā)中的分支與合并是一個(gè)涉及到環(huán)境、方法和技術(shù)平臺(tái)等諸多因素的綜合性難題，在這種場(chǎng)合下，“模式(Pattern)”可能是解決上述 問題的一個(gè)很好的工具。所謂模式，其實(shí)就是解決某一類問題的方法論。你把解決某類問題的方法總結(jié)歸納到理論高度，那就是模式。Alexander給出的經(jīng) 典定義是：每個(gè)模式都描述了一個(gè)在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心。通過這種方式，你可以無數(shù)次地使用那些已有的解決方 案，無需在重復(fù)相同的工作。

在不同的領(lǐng)域有不同的模式，具體到并行開發(fā)領(lǐng)域，“分支模式”是專門針對(duì)并行開發(fā)環(huán)境下分支及合并作業(yè)中的各種不同的操作方法抽象出來的一套方法論。其主要由以下幾部分組成:

結(jié)構(gòu)模式——通過約束和指導(dǎo)分支/代碼線的整體結(jié)構(gòu)，實(shí)現(xiàn)并行開發(fā)的組織結(jié)構(gòu)、開發(fā)模式及開發(fā)過程的約束和指導(dǎo)。

規(guī)則模式——通過對(duì)特定分支/代碼線實(shí)施的約束，實(shí)現(xiàn)對(duì)該分支/代碼線相關(guān)的操作進(jìn)行約束，如訪問控制及合并等操作的約束。

創(chuàng)建模式——提供對(duì)分支/代碼線創(chuàng)建的約束

反模式——以反例的方式展示并行開發(fā)中常見的行為誤區(qū)和陷阱，并提供有效的解決方案。

分支模式在并行開發(fā)中的應(yīng)用難點(diǎn)有兩個(gè)：一是如何根據(jù)企業(yè)的實(shí)際情況選擇適合的分支模式，二是如何構(gòu)建一個(gè)技術(shù)平臺(tái)來將這些分支模式的理論和方法有 效的應(yīng)用于實(shí)踐。為此，我們專門在此開辟專欄和大家分享并行開發(fā)中分支模式相關(guān)的理論、方法以及如何將這些理論和方法付諸實(shí)現(xiàn)的相關(guān)實(shí)踐。

主線（結(jié)構(gòu)模式）

一、分支模式的相關(guān)定義

模式 主線

別名 主干、主錨線、本線、地線（Main Trunk, Main Anchor Line, Home Line, Ground Line ）

場(chǎng)景

在開發(fā)和維護(hù)周期中，因?yàn)楦鞣N原因需要?jiǎng)?chuàng)建多條代碼線，典型的代碼線是發(fā)布線、維護(hù)線和集成線。這在采用每發(fā)布代碼線、并行維護(hù)/開發(fā)線和重疊發(fā)布線 (或者其任何變形模式)的情況下尤為如此。隨著項(xiàng)目的進(jìn)行，會(huì)創(chuàng)建出越來越多的代碼線，從而導(dǎo)致項(xiàng)目的版本樹越來越寬。

連續(xù)的瀑布式分支（應(yīng)該避免的情況）

問題

怎樣確保當(dāng)前活動(dòng)代碼線的數(shù)量在可控范圍內(nèi)，以及避免項(xiàng)目的版本樹過寬過深？

動(dòng)機(jī)

• 通常，每條代碼線在某個(gè)時(shí)間點(diǎn)需要將變更集合并至其父分支。所以越多的代碼線就意味著更多的合并，而越多的合并意味著越多的同步工作。
• 當(dāng)后續(xù)的版本發(fā)布時(shí)，看起來只有在當(dāng)前版本的代碼線上開創(chuàng)一個(gè)新的分支才算是合理的。

解決方案

在每一個(gè)分支樹中保持一個(gè)“主”分支或代碼線作為主干，而不是持續(xù)的瀑布式從分支創(chuàng)建分支從而使分支樹變得寬廣而笨重（在每一對(duì)父子分支之間需要大量的同步工作）

擁有主線的瀑布式分支

當(dāng)為主發(fā)布創(chuàng)建代碼線的時(shí)刻來到時(shí)，我們不會(huì)從前一個(gè)發(fā)布線創(chuàng)建新的發(fā)布線，而是將先前的發(fā)布線合并回主線，然后再?gòu)闹骶€創(chuàng)建新的發(fā)布線。
為特定代碼線或分支合并回來的過程被稱為“主線化”、“主干化”、“歸位”、“錨定”或“接地”（"mainlining," "trunking," "homing," "anchoring," or "grounding."）。

變種 穩(wěn)定接收線（也稱為穩(wěn)定主線、主集成線和基礎(chǔ)集成線（Stable Mainline, Main Integration Line, Base Integration Line））

保持一個(gè)穩(wěn)定的，可靠的主要開發(fā)主干可以用來從其他代碼線導(dǎo)入（接收）穩(wěn)定基礎(chǔ)。在代碼線上不會(huì)直接發(fā)生開發(fā)工作，所有集成工作必須來自其他代碼線（不是一個(gè)單獨(dú)的離散的活動(dòng)分支）。這個(gè)規(guī)則唯一的例外是為了保證代碼線構(gòu)建和功能一致性的集成變更。

（用以接收穩(wěn)定基線的穩(wěn)定主線——實(shí)際上就是通常所說的基線）

LAG開發(fā)線（也稱為主開發(fā)線、中央線和主流）

把主干作為最新的最好的（LAG）會(huì)一直進(jìn)展的開發(fā)線，所有前面的發(fā)布的代碼線都會(huì)在其退休后被合并入其中。主干作為下一步/最后的開發(fā)發(fā)布（不是 維護(hù)，而是開發(fā)，包括顯著的改進(jìn)和新特性）的開發(fā)線使用，因此當(dāng)B2發(fā)布的工作已經(jīng)準(zhǔn)備好開始，而A1發(fā)布已經(jīng)完成或逐漸停止，則建立一個(gè)新的分支來結(jié)束 A1的工作（見延遲分支），而LAG線則用來針對(duì)B2（最新的和最好的開發(fā)工作）發(fā)布的工作。

（LAG開發(fā)主線）

對(duì)于特定代碼線或分支合并到滯后（LAG）開發(fā)線的過程也可以稱為"LAGging," "mainlining," "LAG-lining," or "mainstreaming."。

盡管作為一個(gè)主線使用，LAG線也可以作為主線與穩(wěn)定接收線結(jié)合：

（有一條穩(wěn)定主線用于接收發(fā)布版本的LAG開發(fā)主線）

二、模式的分析

主線模式及其變種主要試圖從分支的結(jié)構(gòu)上約束其不合理的擴(kuò)展和延伸，而盡量使主線成為其他代碼線創(chuàng)建的來源及合并的目標(biāo)。穩(wěn)定接收線（也就是通常所 說的基線）用于接受并保存相對(duì)穩(wěn)定的版本，通常情況下其只接受版本（通常情況下為直接保存版本的鏡像而非合并操作）而不進(jìn)行其他任何操作。

三、主線模式在Subversion環(huán)境下的實(shí)現(xiàn)

如上圖所示實(shí)際上就是有一條基線伴隨的LAG開發(fā)線模式，實(shí)現(xiàn)該模式相關(guān)的約束包括：

1、所有的代碼線（不包括分支）都從主線創(chuàng)建

2、主線以外的代碼線的合并操作都以主線為目標(biāo)

3、基線只接受版本（直接保存版本的鏡像而非合并操作）而不進(jìn)行其他任何操作。

寬松訪問線（規(guī)則模式）

一、分支模式的相關(guān)定義

模式 寬松訪問線（Relaxed-Access Line）

問題 如何確定代碼線訪問控制規(guī)則的限制或排他程度？

動(dòng)機(jī)

• 如果許多開發(fā)者在代碼線上工作，或某一些人缺乏經(jīng)驗(yàn)，那嚴(yán)格的治理是必要的。
• 如果代碼線上發(fā)生的工作具有顯著的風(fēng)險(xiǎn)級(jí)別或難度，則檢入和合并需要更緊密的監(jiān)控和/或驗(yàn)證。
• 保證代碼線一直處于完整的狀態(tài)非常重要，這樣就不會(huì)影響其它工作在代碼線上的人們。
• 如果代碼線對(duì)應(yīng)了特定提升級(jí)別（見階段集成線）或生命周期階段，這也許指明了對(duì)特定代碼線驗(yàn)證一致性的必要性級(jí)別。

解決方案

如果代碼線是用來開發(fā)或維護(hù)（而不是排它或集成），并且工作在代碼線上的團(tuán)隊(duì)規(guī)模相對(duì)較小，人員富于經(jīng)驗(yàn)并可靠，那么給開發(fā)者有相對(duì)寬松自由的區(qū) 域，讓他們做他們已經(jīng)知道如何去做的事情：在一起以及時(shí)的方式工作。使用最小檢查和控制，但是要確保代碼線所有者可以認(rèn)真對(duì)待他的工作，并可以一直知道代 碼線的狀態(tài)以及確認(rèn)完整性是否被特定風(fēng)險(xiǎn)/復(fù)雜開發(fā)任務(wù)危害。

相關(guān)模式

MYOC（合并你自己的代碼）及其變種PYOC（傳遞你自己的代碼）是使用寬松訪問線最常見的副產(chǎn)品（或原因），如果在你的環(huán)境中，風(fēng)險(xiǎn)較小，而且開發(fā)者合并自己的變更到代碼線的交流通暢，那么我們有充足的理由使用寬松訪問。

二、對(duì)模式的分析

這種訪問模式通常適用于沖突不嚴(yán)重（如開發(fā)初期或彼此按模塊獨(dú)立開發(fā)）的情況，要求相關(guān)人員具備一定的水準(zhǔn)以保證開發(fā)的質(zhì)量，而在開發(fā)的后期通常不適用這種模式。

三、寬松訪問線（Relaxed-Access Line）在Subversion環(huán)境下的實(shí)現(xiàn)

如上圖所示（相關(guān)內(nèi)容只是相關(guān)模式實(shí)現(xiàn)的一個(gè)實(shí)例，實(shí)際使用時(shí)可根據(jù)實(shí)際需求對(duì)角色及授權(quán)進(jìn)行調(diào)整）：

1、代碼線的所有者對(duì)代碼線擁有完全的操作權(quán)限

2、主管及EPG成員僅對(duì)代碼線擁有有限的操作權(quán)限（讀）

3、除測(cè)試人員以外的項(xiàng)目成員都對(duì)代碼線擁有完全的讀寫權(quán)限

4、代碼線的所有者以及項(xiàng)目經(jīng)理和配置經(jīng)理?yè)碛袑?duì)代碼線鎖的權(quán)限

大爆炸式集成（反模式）

一、分支模式的相關(guān)定義

陷入的誤區(qū) 大爆炸集成

別名 大怪獸集成

癥狀

由于某種原因，一直不選擇集成，直到（軟件）要發(fā)布的時(shí)候 ，才把所有的分支一下子全部交給倒霉的集成者進(jìn)行集成。經(jīng)常性的增量集成看起來是流行的常識(shí)性規(guī)則（亦稱為：盡早且經(jīng)常合并），大爆炸（的方式）顯然在隔 離和避免風(fēng)險(xiǎn)方面達(dá)到了極致，這是大怪物地結(jié)束合并，結(jié)果不是一個(gè)“大爆炸”，而是以“哭泣”告終。

大爆炸式的集成（需要避免的反模式）

原因

一個(gè)原因是我們未能成功找到盡早集成和經(jīng)常集成的地正確“節(jié)奏”和“脈搏”。有時(shí)‘大怪獸式集成’是“整合恐懼癥”帶來的附加品，在盡力縮小合并數(shù) 量的時(shí)候，結(jié)果會(huì)是一個(gè)延期而至的可怕的復(fù)雜合并的結(jié)尾。因而，在這種情況下，“集成是魔鬼” 變成了自我實(shí)現(xiàn)的一種預(yù)言，并且在失敗的惡性循環(huán)中不斷加強(qiáng)。

影響

太多人都很熟悉所造成的后果，直到一切已經(jīng)太晚，如系統(tǒng)不能正確的構(gòu)建，無法通過測(cè)試，或部分代碼與其它代碼工作不能協(xié)同工作，我們才能發(fā)現(xiàn)這問 題。直到項(xiàng)目生命周期的下一個(gè)階段，這些信息才得到交流，相關(guān)的風(fēng)險(xiǎn)和返工將會(huì)非常巨大，會(huì)導(dǎo)致“合并是魔鬼”或“合并恐懼”的心理。

修復(fù)和預(yù)防

使用盡早經(jīng)常性的集成或使用一個(gè)或更多的變種來確保以一定頻率和間隔執(zhí)行集成，以在時(shí)間充裕，額外工作較少時(shí)盡早分解風(fēng)險(xiǎn)和盡快交流問題區(qū)域。你可 以現(xiàn)在或者將來，或者由你自己決定何時(shí)付出，有規(guī)律的經(jīng)常的集成可以迫使你在每次迭代和集成計(jì)劃中只需要付出很少的努力，通過分解減少隨時(shí)間積累的合并負(fù) 擔(dān)，從而定義了健康項(xiàng)目的“脈搏”。

二、模式的分析

這種大爆炸式的集成在缺乏有效管理的團(tuán)隊(duì)中是經(jīng)常發(fā)生的，我們經(jīng)常可以看到這樣的場(chǎng)景：明天就要發(fā)版本了（尤其是非計(jì)劃的發(fā)布），今天所有的相關(guān)人員都一起合版本，于是大家驚訝的發(fā)現(xiàn)系統(tǒng)出現(xiàn)無數(shù)的合并沖突和缺陷，而在這種情況下，延遲發(fā)布幾乎是唯一的選項(xiàng)了。
要避免這種最好的方式就是通過某種機(jī)制約束分支的周期和合并。

三、大爆炸式集成在Subversion環(huán)境下的規(guī)避方式

如上圖所示，在創(chuàng)建分支時(shí)添加如下約束：

1、創(chuàng)建分支時(shí)定義分支的周期（通常任務(wù)分支都是需要及時(shí)終結(jié)的），并強(qiáng)制終結(jié)

2、創(chuàng)建分支時(shí)定義分支的合并周期和約束方式（包括提醒和強(qiáng)制合并兩種可選方式）

通過上述的約束，可以使分支/代碼線及時(shí)的合并和終結(jié)，從而避免大爆炸式集成的發(fā)生

代碼所有權(quán)（規(guī)則模式）

一、分支模式的相關(guān)定義

模式 代碼線所有權(quán)（Codeline Ownership）

別名 分支所有權(quán)（Branch Ownership ）

場(chǎng)景

作為一名程序員，在一組多代碼線的環(huán)境下，并至少在一條代碼線上開發(fā)。代碼線規(guī)則已經(jīng)為該代碼線定義好檢入/檢出的規(guī)則。有些人要在代碼線上進(jìn)行某些工作，但是該規(guī)則并沒有允許這樣的操作，或者就是規(guī)則對(duì)一些特定事務(wù)的描述含糊不清。

問題

能影響代碼線的動(dòng)作能否執(zhí)行？在保證代碼線的完整性和連續(xù)性的同時(shí)，怎樣做上面的決策?

動(dòng)機(jī)

• “理論上，實(shí)踐和理論是一致的；但在實(shí)踐中，其兩者卻有極大的不同。”沒有一個(gè)規(guī)則能夠涵蓋所有的情況。 代碼線規(guī)則從理論上滿足了需求，但是在實(shí)踐中，則還有必要其他一些東西補(bǔ)充理論和實(shí)踐之間的缺失。
• 如果代碼線規(guī)則不是很清楚，則開發(fā)人員需要將其定義清楚。
• 代碼線規(guī)則是會(huì)被違背的，不管是有意還是無意。
• 代碼線必須保持正確且連續(xù)的狀態(tài)，以避免與正在進(jìn)行的開發(fā)任務(wù)起相反的作用。.

解決方案

為每個(gè)代碼線分配一名所有者（owner），其相應(yīng)的職責(zé)如下

• 如果代碼線的規(guī)則定義不清晰，則定義清楚;
• 如果檢入的配置項(xiàng)與代碼線的規(guī)則相抵觸，則決定讓其保留在代碼線中，還是回退到上一個(gè)版本
• 制定相應(yīng)的規(guī)則，防止代碼線處于含糊不清狀態(tài)或不適用實(shí)際情況
• 在該代碼線上，輔助或執(zhí)行變更的集成
• 決定何時(shí)對(duì)代碼線進(jìn)行凍結(jié)，解凍；何時(shí)代碼線必須結(jié)束生命周期并且合并到主線（Mainline）中

所有權(quán)（Ownership）并不一定意味著排他式的訪問，但卻表示用戶認(rèn)證訪問控制。也許只有代碼線的所有者才能檢入文件（受限訪問線）；或者， 其他人只要在檢入前獲得代碼線所有者的同意，即可檢入代碼線，又或者在檢入后立刻通知代碼線所有者（寬松訪問線）。代碼線規(guī)則必須清楚地定義訪問控制類型 相對(duì)應(yīng)的所有權(quán)類型。通常來講，在代碼線上工作的開發(fā)人員越多，相應(yīng)的所有權(quán)策略也越嚴(yán)格。同樣地，限制程度與代碼線包含活動(dòng)的風(fēng)險(xiǎn)性或是復(fù)雜性，或是對(duì) 穩(wěn)定性的要求成正比。在較小的項(xiàng)目和團(tuán)隊(duì)中的代碼線中所包含較少的關(guān)鍵任務(wù)，在保證代碼線完整性和連續(xù)性的前提下，提供比較隨意，限制較少的訪問控制策 略。

變種 代碼線專屬（Codeline Dictatorship ）

代碼線的所有權(quán)中極其嚴(yán)格的一種形式，其配置項(xiàng)的檢出和分支都是嚴(yán)格受限的，當(dāng)然更包括檢入。專屬者可能是一個(gè)人，或是一個(gè)小組。一個(gè)常見的例子就 是“遠(yuǎn)程開發(fā)線”。遠(yuǎn)程開發(fā)人員可能被禁止從非遠(yuǎn)程分支中創(chuàng)建新的版本或是分支，因此，本地分支僅僅是“主人（master）”開發(fā)的地方。這實(shí)質(zhì)上就是 ClearCase Multisite定義的“分支主人身份（branch mastership）”的概念。

導(dǎo)致的場(chǎng)景

• 只有一個(gè)人對(duì)代碼線的連續(xù)性和完整性負(fù)責(zé)。這樣，代碼線比較可能處于一種穩(wěn)定的狀態(tài)。
• 保持所有者對(duì)代碼線的狀態(tài)負(fù)責(zé)，降低了代碼線規(guī)則被踐踏或代碼線被用于錯(cuò)誤目的的可能。
• 代碼線的概念完整性由一個(gè)頭腦，也就是所有者維護(hù)，作為解決代碼線問題的單一權(quán)威。

二、模式的分析

代碼線所有權(quán)/代碼線專屬模式強(qiáng)調(diào)的是代碼線所有者對(duì)代碼線的控制權(quán)，適用于由專人（或角色）對(duì)代碼線內(nèi)容進(jìn)行全權(quán)負(fù)責(zé)的情況下使用

三、代碼線專屬（Codeline Dictatorship ）在Subversion環(huán)境下的實(shí)現(xiàn)

如上圖所示（相關(guān)內(nèi)容只是相關(guān)模式實(shí)現(xiàn)的一個(gè)實(shí)例，實(shí)際使用時(shí)可根據(jù)實(shí)際需求對(duì)角色及授權(quán)進(jìn)行調(diào)整）：

1、代碼線的所有者對(duì)代碼線擁有完全的操作權(quán)限

2、主管、項(xiàng)目經(jīng)理及配置經(jīng)理僅對(duì)代碼線擁有有限的操作權(quán)限（讀）

3、代碼線的所有者擁有再授權(quán)的權(quán)限

代碼線規(guī)則（規(guī)則模式）

一、分支模式的相關(guān)定義

模式名稱 代碼線規(guī)則

別名 每代碼線規(guī)則

適用環(huán)境 使用多條代碼線開發(fā)軟件的情況下。

問題 開發(fā)人員如何知道需要將他們的代碼存入哪條代碼線中，并且何時(shí)保存？

動(dòng)機(jī)

• 每條代碼線都有不同的目的 ；
• 代碼線的名稱通常能暗示其目的；
• 代碼線的名稱通常不能全部表達(dá)代碼線的使用要點(diǎn)；
• 如果代碼寫入到錯(cuò)誤的代碼線，而這錯(cuò)誤的變更必須要回退，導(dǎo)致生產(chǎn)率的降低；
• 使用正規(guī)文檔描述代碼線的用法會(huì)很有幫助，但是需要額外的記錄和維護(hù)；
• 這個(gè)文檔太過拘謹(jǐn)就會(huì)有一點(diǎn)過度規(guī)劃和專橫了；

解決方案

除了給分支/代碼線起一個(gè)有意義的名稱之外，要給每條代碼線明確目的，并使用簡(jiǎn)捷明了的策略描述其目的。其中應(yīng)該包括以下一些要點(diǎn)：

• 代碼線包含何種工作，例如：開發(fā)、維護(hù)、一種特定的版本、功能或是子系統(tǒng)；
• 配置項(xiàng)在怎樣的條件下才能被檢入，檢出，分支，合并；
• 對(duì)于不同的個(gè)人，角色，組，代碼線該設(shè)置怎樣的讀寫權(quán)限的限制；
• 導(dǎo)入/導(dǎo)出關(guān)系：代碼應(yīng)該從其它哪些代碼線中接受變更，同時(shí)應(yīng)該將變更應(yīng)用于其它哪些代碼線；
• 代碼線的生命周期或結(jié)束條件；
• 預(yù)期的工作負(fù)載以及集成頻率。

讓規(guī)則簡(jiǎn)短扼要：一個(gè)簡(jiǎn)單的經(jīng)驗(yàn)方法是1-3段（各自25行25個(gè)字符，一頁(yè)絕對(duì)是上限）。

請(qǐng)切記不是所有的代碼線策略都需要上面所有的信息，只需要制定自己所需要的。一些版本控制工具允許在每個(gè)分 支、代碼線的名稱上附加詳細(xì)的注解，這是存放合適簡(jiǎn)短代碼線規(guī)則描述的理想地方。開發(fā)者可以通過包含代碼線名稱的命令來查看代碼線規(guī)則，而無需在別的地方 找文檔。否則，將代碼線規(guī)則放在大家都知道的隨手可得的地方（或許提供簡(jiǎn)單的命令或宏，對(duì)于給定代碼線名稱可以快速顯示規(guī)則）。

二、對(duì)模式的分析

代碼線規(guī)則這種模式實(shí)際上就是一種最基本的分支/代碼線使用規(guī)范，它強(qiáng)調(diào)每條分支/代碼線都應(yīng)該以快捷而有效的方式記錄其相關(guān)的信息，并且這些信息可以隨時(shí)被方便的訪問。

作為更進(jìn)一步的要求，除了將相關(guān)信息記錄在案，在某些情況下對(duì)其中部分內(nèi)容（如分支的周期及合并的頻率等）進(jìn)行提醒甚至約束也是有其必要性的。

三、寬松訪問線（Relaxed-Access Line）在Subversion環(huán)境下的實(shí)現(xiàn)

如上圖所示：

1、每條分支/代碼線代碼線創(chuàng)建時(shí)都有效的記錄相關(guān)信息

2、對(duì)分支的生命周期和合并周期提供約束控制

注：上述功能的實(shí)現(xiàn)是基于在系統(tǒng)底層屏蔽了所有不受控的分支創(chuàng)建操作，而只能在特定應(yīng)用系統(tǒng)內(nèi)進(jìn)行分支/代碼線的創(chuàng)建，從而使所有分支/代碼線相關(guān)操作都處于受控狀態(tài)