版本控制練習

Question

在我目前的工作中，主管的做法是隻檢查生產就緒代碼。最近，我參與的這個項目由3名不同的開發人員負責，文件重疊。這意味着手動整合更改，儘管某些更改需要一天，然後才完成。我想看看這是否是一種常見的做法，並獲得關於如何改變這種做法的建議，同時我知道很多時候我的意見在事物的宏偉計劃中意義不大。這是應該單元測試檢查，但對我來說

Answer 1

根據您的源代碼管理系統，您可以使用各種方式來處理這種情況。

私人分支：允許你檢查的，雖然你走了，在適當的時間合併來回代碼工作。

擱置集/ pacakaged變更：讓您存儲的變更和周圍給他們審覈 - 確保他們生產準備在檢查之前

至於這是否是工作以適當的方式，我們不允許在沒有事先審查的情況下登記到主要分行。要通過審覈，您的代碼必須通過各種自動化工具，然後您的同行審覈人員必須接受。對於「生產準備」的一些定義 - 就是這樣。因此，我們做你喜歡的事情。但是，我們使用私人分支機構來確保在進行中仍然可以辦理登記手續，而其他登記入住手續不必干涉。

如果生產準備就緒意味着在集成環境中進行測試，那麼它聽起來像您可能需要登臺分支或類似的東西。

Answer 2

代碼，「生產就緒」意味着它通過集成和系統測試了。你不能這樣做，直到代碼凍結，所以我看不出你如何能做到在每一個檢查之前。

Answer 3

我個人不同意這一點，因爲有時這是趕上問題碼用更少的最佳方式經驗豐富的開發人員（通過在他們工作時看到它）以及當您「提早並經常檢查」時，如果您確定之前做出的某些更改實際上更好，則可以回滾到您所做的更早更改（如開發人員）理念。

Answer 4

豈不是有回購的測試分支，可以有非「生產就緒代碼」檢查在更改完成並經過測試後的好主意嗎？

主幹線不應該代碼在檢查打破了構建和沒有通過單元測試，但分支機構不具備有全部到位這些限制。

Answer 5

我認爲這可能是我們用戶的版本控制，VSS與缺乏時間學習分支相結合。我真的很喜歡夜間檢查以幫助發展並避免「走向黑暗」的想法。我可以看到他對中繼線有抵抗力，但也許會建立一個開發SS，並且當代碼準備就緒時，就會將其移至生產SS。

Answer 6

從我見過的做法來看，術語生產質量被用作'嚇人'來確保人們害怕破壞樹頂，而不是一個誠實的壞事，因爲樹的頂部應該始終工作，如果可能的話。

我會說，最好的做法是，你應該只在樹的頂端，被合併不同的（即獨立的）功能組件。如果你對同一個源文件的deltas有重要的重疊，我認爲這可能表明項目管理已經破裂的某處，並且這些開發者應該在將它們的更改合併到單獨的集成分支之前，主線來源。一個開發者說他們測試他們的東西是無關緊要的，因爲他們測試的東西已經改變了！

試圖解決你的主線代碼行上的集成問題將不可避免地拖延其他無關的提交。

Answer 7

假設你在一個集中的版本控制系統（如Subversion）的工作，並假設你有「軀幹」（其中的最新工作良好的代碼存在）的概念：

如果您研究「功能分支」/「實驗分支」中的新功能，那麼可以提交遠未完成的代碼。 （當功能完成後，您將行爲良好的結果提交到「中繼」中）。

但是，如果將非編譯/明顯不工作的代碼提交到「主幹」中，您將無法贏得人氣競賽或一個「發行分支」。

語用程序員有一本名爲Pragmatic Version Control using Subversion的書，其中包含關於分支的建議部分。

Answer 8

入住早，檢查往往主要有兩個原因 -

1 - 它可能更容易整合代碼

2 - 如果你的電腦的爆炸幾周的工作還沒有走

Answer 9

@bpapa

工作文件夾服務器的夜間備份將阻止超過一天的工作失去更多。

@tonyo

讓我們看到需求文檔完成後的第二天，我們完成了編碼。這是否告訴你我們的項目管理？

我們是一家小店，雖然你會認爲改變很簡單，但這裏有一些對舊的方式不屈不撓。

Answer 10

我特別喜歡的方法是在倉庫中擁有不同的生命週期版本。也就是說，例如，開發人員檢查正在處理的代碼的開發版代碼;那麼你可以有一個測試版本，你可以在其中添加beta修復程序到你的代碼;然後是生產版本。

這種方法存在明顯的開銷，例如您將在本地計算機上擁有更大的工作空間這一事實，您需要有一個遷移過程才能將代碼從一個階段移動到下一步（這意味着在執行與遷移一起進行的集成測試時會凍結代碼），並且根據項目的複雜性，您可能需要具有更改設置，環境變量，註冊表項等的工具。
所有這些都是很痛苦的事情，但你只做一次，一旦你完成了這一切，讓代碼的不同階段的工作變得輕而易舉。

Answer 11

從VSS開始切換到更可靠的功能&功能豐富。見How to convince a company to switch their Source Control

然後應用已知的良好做法：

• Check in often
• 經常拿起別人的變化，來簡化合並
• 使用快速unit tests，以確保每一個變化達到最低杆
• 要求檢入代碼始終構建，並始終通過測試。

現在您不會在現場「準備好生產」：在部署之前，您仍然需要幾周的時間才能測試&修復程序。讓您的時間減少對您而言非常棒，對您的客戶而言非常棒，因此投資於：

• 高質量的自動驗收測試。