版本控制應考慮哪些簽入策略？

我的任務是幫助爲我公司的TFS 2008安裝設置流程模板和簽入策略。版本控制應考慮哪些簽入策略？

除了三項簽到政策（簽入行爲必須有評論意見，代碼文件必須經過同行評審，必須有與簽入相關的工作項），我被問到考慮和實施任何其他。

什麼是一些最重要或有用的策略來執行版本控制？

來源

2009-07-29 Phil.Wheeler

同行評審不一定是簽入的先決條件。您可以先登記，同行審查已提交的文件，然後在審查後將文件提交給另一個分支。 – Dan 2009-07-29 03:07:39

越少越好。

通常在一個組織中，您希望緩解簽入的摩擦，以確保您鼓勵開發人員頻繁進行小型離散簽入，而不是一次簽出一堆東西。然後，再次，您要確保爲每個需要它的人提供有效的代碼庫，並捕獲您需要改進軟件交付流程的數據。

就個人而言，執行變更集註釋和工作項關聯策略的策略是可以的 - 因爲它們捕獲當時非常容易記住，但之後很難找到的元數據。它還鼓勵開發人員養成有工作項目來跟蹤所有工作的習慣 - 即使是實驗開發或尖峯。

使用分支或其他過程可能會更好地執行同行評審過程，而不是強制每次簽到同行評審 - 但這取決於您的過程。還要記住，您可以在TFS中使用強制簽入註釋來捕獲代碼審閱者等元數據。辦理入住手續的注意事項與入住政策略有不同，且經常混淆。

如果您想了解更多有關簽入政策的討論，請查看blog post I did on the balancing act a while ago。此外，爲了聽取更多有關簽到政策的討論，我最近與一位Team System MVP同事談論了他們使用TFS的情況，並記錄了一個播客，這可能很有趣（Radio TFS, Using TFS with Ed Blankenship）。最後，我們還在2008年做了一個Radio TFS episode all about check-in policies，這可能是有趣的。

來源

2009-07-29 08:48:54

，我們按照我們公司的一些規則：

提交一次有關同一任務的所有變化（這將有助於審查變化和今後的回滾或者如果需要合併）。
基於模板的註釋（例如：前綴所有註釋的代碼代表所做的事情，+添加， - 刪除，*更新，！重要修改等）。
顯然總是簽入代碼編譯，並完成工作的主線。
辦理每日未完成的工作到分支機構。

來源

2009-07-29 02:41:54

我不認爲「原子提交」意味着你認爲它的作用。這是VCS的一項功能（不是），而不是團隊策略。我認爲你的意思是「一次簽入所有與同一變更相關的文件」。 – 2009-07-29 02:59:37

你是對的，但我們在我們公司中這樣說。 – 2009-07-29 03:01:05

不要打破構建！當然，找到一種自動化的方法來檢查並拒絕簽入是挑戰。

來源

2009-07-29 02:41:57 JustJeff

這是一個非常微不足道的。另外我認爲自動檢查來源不是政策本身，它更多是一種控制機制或確保政策得到遵守，在這種情況下，始終簽入可建立的政策。 – 2009-07-29 03:26:46

坦率地說，政策越少越好。您擁有的政策越多，不使用版本控制的動機就越大。然後會發生什麼：

代碼是在並行的，不受控制的源代碼控制系統上開發的，只是最終的修訂版本轉向官方版本。
人們儘可能延遲提交，降低了他們對其他開發人員的可見性。
人們實際上可以避免承諾一些事情，如果他們能夠避開它，有些人會找到一種方法來擺脫它。

實際上，我認爲您的三項登記政策已經太多了。例如：

讓代碼在簽入之前進行同行評審使得在此存儲正在進行的工作更加困難。相反，如果源代碼管理系統允許（和許多）控制源代碼是否經過同行評審。對於某些系統，您可以爲修訂創建生命週期，其他人可以創建分支，還有一些系統可以使用標記。
讓工作項目與簽入相關聯使得開發人員無法進行探索性編程，或對可能的改進有主動性。它扼殺了開發者。相反，確保進入集成測試或用戶驗收測試的任何修訂，更不用說生產本身，與工作項目相關聯。

這可能聽起來反對企業，但它只是我們在幾十年的軟件開發中學到的一些東西。大多數企業組織都沒有涉及到這一點，但最終他們會這樣做。所以，你可能會走相反的道路，但不要說沒有人告訴過你。

我推薦Agile Manifest，特別是Lean Software Development的一般原則。或者，考慮到Stack Overflow設計理念，讓系統獎勵您想要的行爲。

來源

2009-07-29 02:55:15

善用風險投資系統是開發者作爲團隊成員的責任的關鍵部分，無論政策，政策是否按照相同的方式進行使用，如編碼指南（您認爲它們也是無用的？），在我的公司，VC準則是編碼準則的一部分。 – 2009-07-29 03:23:03

@Lucas S.無用？在我使用「無用」一詞或其任何同義詞的地方，我的整個答案中是否有任何地方？我沒看到它。把它指向我，我會把它擊倒！良好地使用VC系統對軟件開發至關重要，這就是我提倡不讓人們避免使用它的原因。至於「開發人員責任」和「團隊合作伙伴」，這是通過領導和管理在開發人員中產生的東西。這不是違反不合理政策並假定他們會工作的藉口。 – 2009-07-29 03:43:26

TFS中還有Shelve功能。這使您可以有效地創建迷你開發者分支和他們的工作代碼。 – 2009-07-30 12:32:17

儘量減少在同一分支上工作的開發人員數量。這樣分支在編譯，單元測試和迴歸方面保持穩定。如果開發人員進行編譯檢查，但他的代碼打破了應用程序的關鍵區域（如登錄），這是一場噩夢。

如果您確實需要10多位開發人員將代碼檢入同一分支，我們已經啓動了一個電子郵件策略，開發人員檢查警告所有人他們正在簽入，以免任何人嘗試更新他們分支機構在辦理入住手續時的副本。有時候，我們必須有相反的地方，我們在該日期留出一段時間禁止入住，以便更新安全。

來源

2009-07-29 03:04:38 Alan

我們所使用的那些，我對TFS工作是：

代碼分析
- 這將確保所有的代碼是在開發者機器上編譯它在
工作項目協會
- 如果您已經做了更改，應該有一個分配任務！
最後成功打造
- 使用TFS構建服務器來檢查，在源代碼控制當前代碼一個獨立的機器上編譯
入住註釋（TFS電動工具的一部分 - http://msdn.microsoft.com/en-us/teamsystem/bb980963.aspx ）
- 很高興能夠看到檢查概要，而無需轉到工作項目

來源

2009-07-29 03:07:23

版本控制應考慮哪些簽入策略？

回答

相關問題