顛覆，5個開發者小團隊的最佳實踐？

Question

我們通過Assembla與CI Team City進行了svn安裝。我瞭解源代碼控制，我的團隊對它有所瞭解嗎？我們應該如何繼續工作？目前，我們的環境並不像它應該那樣組織起來。我也想讓Trac爲我們的團隊工作。我們應該怎樣做每個人在自己的分支上工作？完成後將更改合併回主幹？或者讓他們幹掉幹線，希望Teamcity能抓住壞的東西？

Answer 1

1.我們應該如何與繼續工作？ 如果團隊是全新的配置管理，你的短期目標應該是讓他們在一個可控的方式與他們的工作的干擾最小的工作。這意味着您需要將您的個人配置目標分爲短期和長期目標。隨着團隊學習，準備重新定義你的長期目標！

2.現在我們的環境，是不是有組織的，因爲它應該是。 一個好的配置管理員會一直這麼想。你想要做的最後一件事是給出這樣的看法，即你更喜歡過程而不是「真正的工作」，所以要繼續前進，思考進化，而不是革命。就像軟件一樣，定義團隊過程需要一個「計劃」和良好的溝通。

3.我也試圖讓Trac系統爲我們的小組合作。 好動。最初，TRAC將允許您的開發人員查看正在發生的事情。但是，它也有門票，里程碑，修訂版，優先事項以及其他令人困惑的工具，可能會讓開發人員感到困惑。所以，首先，使用trac作爲svn時間軸和方便的差異工具的視圖。當他們對工具集本身感到滿意時，引入門票/里程碑等等，並且準備在沒有/不需要時使用這些工具。

4.我們應該做有自己的分支機構每個人的工作？完成後將更改合併回主幹？ 最終，也許。但是你有沒有定義分枝/合併會爲你解決的問題？記住，你的團隊可能永遠不會遇到這樣的問題。我的建議是等到你面臨問題，然後在你的指導下解決問題。

5.還是讓他們工作過的樹幹和希望的TeamCity會趕上不好的東西？ 首先，是的。然後介紹當你遇到問題時你所瞭解的關於CM的所有好東西，而不是之前。

記住 - 您正在構建一個軟件產品，而不是一個很好的配置管理系統。所以，保持簡單，並且只使用工具/流程，讓您能夠以團隊的形式構建更好的產品。您明顯瞭解了配置管理的價值，因此您的開發人員也應該學習。引導他們，不要強加於他們。從顯而易見的東西開始（「SVN讓我們以受控的方式共享代碼」），並從那裏使用您的經驗。祝你好運！

Answer 2

我們應該怎樣做每個人都有自己的分支？完成後將更改合併回主幹？

我通常不會贊成這一點，因爲分支每個開發商是笨重的，並且對於給定的開發者通過觀察一個讓別人都正在這樣的理解很難科。你可以通過要求每個人在每次提交時重新合併到主幹來緩解這一點，但爲什麼要有一個分支呢？

還是讓他們去幹掉Trunk，希望Teamcity能抓住壞的東西？

我的建議是讓開發者接受制定團隊規則：每個人都更新並提交給中繼，並且他們在提交之前在本地運行（全部）測試。 Subversion中的分支更有效地用於特徵集合，比如對應於即將發佈的版本，而不是單獨的特徵測試地點。

我認爲你的CI應該是一個安全網，以提醒你事情並不處於你期望的狀態。但是，如果你的開發人員明白他們不應該首先檢查不通過的代碼，那麼這會有所幫助。

Answer 3

1 - 更新
2 - 代碼
3 - 測試
4 - Update'n'merge
5 - 測試
6 - 提交

Answer 4

分行SVN是不容易處理與他們在git中一樣。所以我認爲大部分的日常工作都應該在幹線上進行，並且在分支機構中只會出現大的破壞性變化。

注意：這是我們如何在我的公司工作，它工作得很好。

Answer 5

我發現自己處於類似的情況，我們是一個三人團隊，儘管我的經驗有限，並且我正在學習，但我一直在推動源代碼控制。我發現這篇文章非常有用：http://www.ericsink.com/scm/source_control.html

如果你的團隊還沒有閱讀它，他們肯定應該 - 這是一個很好的起點。

在嘗試過每個人都在他們自己的分支，然後合併到幹線方法，我可以告訴你從我們的錯誤，至少可以說是痛苦和混亂。如果你是最有經驗的人，而且他們是新手，那麼你有可能會承擔將所有這些分支合併在一起的責任......這並不好玩。

從樹幹上跑下來的每個人都是迄今爲止最痛苦的方式，我至今仍然說，與之前的操作方式相比，這幾乎是一種快樂。你們都可以受益於彼此對單獨文件的改進，差異會自動更新和合並（除非有衝突）。它也可以讓你的團隊習慣於版本控制的工作原理，慢慢地你會更加熟悉它的機制，然後它將值得探索分支&合併。

簡而言之：嬰兒學步:-)

這將在長期內還清。

Answer 6

這是我們如何使用它：

1. 所有變化trunk
2. 任何實驗發生的呢？分支它，與它一起工作，直到你滿意。合併回trunk。
3. 所有主要版本的標籤

Answer 7

我已經使用svn那種方式，從來沒有抱怨過。我認爲你的策略取決於你正在開發什麼樣的軟件。就我而言，它是許多不同客戶使用的產品，可用於關鍵環境中的多個不同版本（工廠自動化）。

1. 樹幹，必須始終編譯。
2. 的標籤對於每個發行
3. 所有的修復和輕微的發展必須在樹幹上完成。
4. 每個版本的主版本的分支。
5. 所有主要的發展都在專門的分支上完成。質量保證後合併。
6. 所有修補程序也在受支持版本的每個分支上完成。

它可能看起來很沉重，但它工作正常，它可以爲許多用戶服務。對於這種關鍵軟件，每個人都想確定新版本中的內容。

如果你沒有這種約束，1〜3個就足夠了。與分支合作有時很痛苦。

如果你需要同時運行幾個大項目，你可能要考慮一個DVCS像水銀或Git的。