使用xcode（objective-c）的svn（subversion）的最佳工作流程是什麼？

Question

我們一直在使用svn和xcode兩個星期，並碰到許多尷尬的問題，這可能是由於濫用和缺乏經驗。我們的ios團隊由初級團隊成員組成，因爲所有高級程序員都不能編寫objective-c。

1. 資源文件不包含在svn中，每次設計人員更新資源（圖像，sqlite）時，開發人員都必須手動將文件導入到項目中。程序員解釋說，這是xcode的一個繼承問題，詳細說就是在程序第一次運行時解壓縮資源，爲了更新資源，他們需要直接將資源複製到項目和模擬器中。
2. 開發人員在合併時總是重構。他們解釋說，每次合併時，該項目都會無法解決，並且必須從頭開始重啓，這應該會更快。
3. 根目錄中散佈着版本目錄，根本不太對。我知道應該使用標籤，但不知道何時或如何。
4. 我一直在修補配置文件，特別是哈德森，但與奴隸建設者（缺少xcodeproject）運行錯誤。我應該使用bash腳本嗎？

那麼在mac下版本控制的最佳工作流程是什麼？

Answer 1

一般來說，我會說第一步對如何在命令行環境中使用svn有一個很好的基本理解。有一些基本操作（標記，設置「忽略」屬性）很難（不可能）在XCode中執行（至少在XCode 3中）。對於一個習慣於在通用的Unix/Linux環境中使用svn的開發人員來說，實際上他們不需要學習XCode特有的東西 - 只需排除build目錄和每個用戶的XCode設置文件（參見下文）。

（1.）不正確。沒有理由你的圖片等不能包含在svn中。正常的XCode設置應該是你的圖像（等）將位於源文件的「Resources」文件夾中，並作爲XCode版本的「Copy Bundle Resources」階段的一部分複製到應用程序映像中。

整個XCode項目文件夾中應包括SVN，但下列情況除外：

• 的「構建」目錄
• 每個用戶的XCode設置/歷史AppName.xcodeproj/* pbxuser和。AppName.xcodeproj/* mode1v3

你可能想告訴SVN通過執行類似忽視這些目錄：

svn propedit svn:ignore . 

（2.）沒有理由的東西應該發生「無法解釋的」。如果沒有別的，在終端窗口中運行一個手冊svn update，它會告訴你它更新的是什麼文件。 （3.）標準做法是在根目錄中有「trunk」，「tags」和「branches」目錄。樹幹就是你通常與工作，所以第一步一個新的開發將採取對檢查出的最新的「主幹」版本

svn co svn+ssh://host.com/repository/AppName/trunk AppName 

做一些改變後，將它們保存到存儲庫svn commit（或XCode的「SCM」菜單中的「Commit Changes ...」）。使用svn update（或XCode中的「更新至」）獲取其他開發人員所做的更改。

要標記釋放，複製trunk到tagname：

svn cp svn+ssh://host.com/repository/AppName/trunk svn+ssh://host.com/repository/AppName/tags/version1 

（4）我沒有與哈德森的經驗，所以我不能對此發表意見，雖然「失蹤xcodeproject」聽起來像也許從svn中可能會缺少AppName.xcodeproj目錄。

Answer 2

我大致贊同David Gelhar的回答。

除了第1項之外，您實際上可以承諾項目源代碼中的所有內容，包括資源，但還有一些更好的選擇，比如您的.pbxuser文件。這blog post是一個很好的資源。

Answer 3

你已經提到了一些問題，其中幾個IMO與Xcode或Subversion幾乎沒有關係。讓我們把你的編號項目：

1. Subversion可以絕對處理資源文件，你應該用它來控制這些文件。設計師可以也應該被教導使用svn在命令行中檢查和檢出文件，或者應該給予（並訓練）其中一個GUI svn客戶端，例如Versions。

2. 這聽起來像你的初級開發者也應該接受Subversion的培訓。確實合併會導致問題，但沒有任何事情會導致您在任何方面從頭開始。許多商店有一套簡單的規則，例如：a）主發展分支應該始終沒有錯誤或警告地構建; b）如果您在合併（或執行其他任何操作）時打破了主要的開發分支，則需要儘快修復它。開發人員可以合併他們的修改並修復在他們提交到主分支之前出現的任何問題，所以主要分支曾有被打破。

3. 傳統的顛覆設置有樹幹，分支和標籤目錄。你不必這樣做，但人們會這樣做，因爲它運作良好。請閱讀（並請您的團隊閱讀）Version Control with Subversion，以徹底解決所有這些問題。印刷版可從O'Reilly購買 - 至少購買幾張。具體如何組織倉庫並不像讓團隊同意（並堅持）某些組織方案那麼重要。

4. 我對哈得遜或一般持續整合沒有看法。但是，我懷疑實施CI會給你提供很多幫助，直到你將其他問題分類。

其他的想法：

• 它的時候你的高級開發人員學習一些Objective-C。讓初級開發人員來教他們 - 兩個小組都會學到很多東西。
• Xcode真的不應該是一個很大的因素。當然，它已經集成了對Subversion的支持，但它仍然只是一個svn客戶端，用戶仍然需要知道如何進行分支，如何合併，如何解決衝突，創建分支和命名標籤等的約定你的組織等

爲了解決你的實際問題，典型的工作流程是這樣的，這取決於當地的慣例：

• 開發商開始完成一項任務。在缺陷跟蹤系統中打開任務，輸入要修復的bug的分析或要實施的功能，輸入要更改或添加的代碼的計劃或設計，輸入時間估計或難度級別或類似，可能會進入一個測試計劃的變化。
• 開發人員爲更改創建一個新分支，或者將他們自己的分支與主分支保持同步。
• 開發人員實施變更，經常向其開發分支提交，以避免丟失工作，以便他們可以輕鬆地返回到之前提交的版本。
• 準備就緒後，開發人員將主開發分支簽出到他們機器上的另一個目錄。然後，他們可以將更改合併到該目錄中，以確保項目建立並且沒有任何內容因其更改而中斷。
• 開發人員提交已更改的主開發分支。
• 開發人員更新缺陷跟蹤系統中的任務。

開發人員之間通常會有一些非正式溝通，這樣兩個人最終不會在同一時間對代碼的同一部分進行重大沖突的更改。其中一些可以由分配任務的人來處理，但是作爲團隊工作良好的開發人員通常會了解誰在做什麼。如果情況並非如此，或者即使是這樣，您可能也需要實施一些改善溝通的做法，例如定期進行代碼審查，一起吃午飯等。