首先，給出上一篇內容的word下載：
下面會給出本文的Word文檔下載。另：本篇僅供參考，希望能者補充。
TFS源代碼管理的8大注意事項
目錄
2. 如果代碼沒放在源代碼管理軟件里，等於它不存在... 2
TFS具體使用請參考此鏈接：http://msdn.microsoft.com/zh-cn/library/ms181382.aspx
源代碼管理軟件是我們工作的必備工具，是許多開發團隊的血液。那么如何更好的利用TFS進行源代碼管理呢？
1. 為什么使用TFS 2012進行源代碼管理
為什么使用TFS，從源代碼管理方面來說，TFS具有以下優勢：
l 與Visual Studio無縫結合，方便開發者進行源代碼管理
l 支持代碼審閱與討論
l 支持郵件通知
l 支持Web訪問與管理
l 支持工作項以及BUG等管理
l 不會上傳.NET開發時生成的垃圾文件
l 自帶版本合並以及比較工具。
l 支持數據庫版本管理
l 自帶很多管理工具（測試管理器、反饋客戶端、界面設計工具等等）
2. 如果代碼沒放在源代碼管理軟件里，等於它不存在
每天重復讀這句話——“使用源代碼管理軟件是唯一的有效措施”。除非你在工作時使用項目的源代碼管理庫來控制代碼版本——否則代碼等於沒有存在過。
顯然你曾發覺在你的本地機器上運行良好的代碼在其他人那里運行的效果並不理想。是不是？他們不能獲取你的最新版本，他們沒法去歸並代碼文件，你沒有正確地部署它（參考 you're deploying it wrong）而且如果你的 SSD 硬盤壞了的話你將永遠地失去你的勞動成果。
只要你保持這個心態——代碼只有提交后才是真的安全，才是其他良好編程習慣的保障。你可以把你的任務划分成許多很小的單元以便你逐一提交。你需要頻繁地這么做。你就不必擔心你的硬件會不會出棘手問題。
不過更重要的意義是（至少對於你的團隊領導來說），通過源代碼管理軟件可以看到你做了什么。使用圖表並列出項目清單是個好方法，不過怎么知道他們實際上在做些什么？而使用源代碼管理軟件進行工作就能看得一清二楚了。
3. 要早提交，常提交，並且不要覺得麻煩
關於前面那點，避免“幻影代碼”（就是只能在你的機器上看到的代碼）的唯一方法是經常提交你的任務並且不要覺得麻煩。它可以解決你的問題，不過這樣做也會對你的工作產生其他的影響：
1. 每個提交的修訂都會為你提供一個還原點。如果你完全把代碼搞砸了（沒騙你，我們都這么做過），你是希望恢復到一個小時前的工作還是一周前的工作？
2. 歸並文件時會出現的危險會隨着時間不斷增加。歸並文件一直很麻煩。如果你不是每天都保持提交代碼，某一天你會突然發現你和其他人的更改內容會有 50 多個沖突。你不會為此感到高興的。
3. 它促使你把任務分離成分散的單元。通常人們都是快完成的時候才提交的，因為他們想把代碼做成一個完整的邏輯單元模塊。不過龐大的任務不可避免地要分離出較小的分散功能，而頻繁地提交它們會使你更了解它們，你可以一個個地構建並提交。
如果你做到這些，你的提交歷史不可避免地開始類似於一種半規律的樣式，里面每個工作日都是在提交任務。當然不總是這樣，也有停下來重構或測試，或者其他合理的活動也會中斷標准的開發周期。
然而，當我在看一個獨立的——尤其是完整的項目時，每當發現我們在一個標准的開發周期里，有一天或幾天什么都沒有做，我便會非常擔憂。我之所以擔憂是因為這意味着什么地方出問題了。一般不是有人正在想方設法要把問題搞定的話，就是因為卡在某個問題上而導致項目完全沒有進度。無論到底是什么情況，源代碼管理軟件都會告訴你出現問題了。
4. 提交前要檢查你更改了什么
往源代碼管理軟件里提交代碼的步驟其實非常簡單。（你恐怕會困惑上一條為什么說的那么麻煩。）一般只要發現文件內容有變更時都會不顧后果地把文件傳上去。像這樣——“我的項目根目錄下有文件內容變更了，我要快點提交上去！”
如此會發生一件（或兩件）事情：首先，程序員會沒有意識地把目錄下的垃圾代碼文件也上傳上去。一些人看到類似下面的SVN提交窗口時，就會點擊“選擇全部”然后提交——這樣源倉庫里就會被本不應該存在的未調試的文件和其他垃圾文件給弄亂。
或者是，程序員實際上並沒有檢查他們更改過什么就把文件上傳了。當你在工作中處理配置文件或項目定義文件時很容易就不經意把那些不想提交的文件給上傳了，而且那些文件很可能就被別的程序員用到了。
5. 寫提交信息時一定要認真
這是一個古老的諺語（出處不詳），大意是說“寫每一條提交信息時就好象等下會讀到它的人是一個斧頭殺人狂，而且他還知道你住在哪里”。如果我是那個殺人狂並在研究你的代碼想追蹤 bug 的話，看到的提交信息全部都是“代碼更新了”，小心，我會來砍你的！
我的解決辦法就是解釋清楚為什么要提交新的代碼。每次你對代碼進行更改都是有原因的。可能什么地方會崩潰。可能客戶不喜歡現在的主題顏色。可能你僅僅要調整一下構建配置。無論是什么，這都是有原因的而且你要把原因用文字保留下來。
為什么？這樣做的原因有很多，而且在不同環境下各不相同。舉個例子，使用“歷史記錄”特性或其他類似的功能顯示出誰改了代碼那些地方。如圖：
這是一個可以隨時觀察代碼更改的軟件的一種。無論我想了解一個文件的完整更改歷史，還是只想知道團隊昨天做了什么，留下一個描述性的相關記錄意味着只要不經意一瞥就能知道是什么情況了。
6. 使用代碼審閱提高代碼質量
代碼審閱可以提高代碼質量。
Visual Studio2012包含了源自於Team Foundation Server的代碼審閱工作流。具體使用請參考此鏈接：http://msdn.microsoft.com/zh-cn/library/hh474795.aspx#code-review-request
7. 一定要管理好數據庫的版本
這一點是我們都知道必須要做的，但是很多人覺得它麻煩。問題是很多（或者是大部分）應用程序沒了數據庫就不能運行。如果你沒有管理好數據庫，那你實際上做的就是一個不完整的完全無用的應用程序。
老實說，如果你沒有管理好你的數據庫版本，你的開發會伴隨着很大的問題。在更改數據庫的時候沒有源代碼的管理，沒有還原點，並且很難和團隊密切合作。使用數據庫版本控制系統可以使開發更輕松。
那么使用，Visual Studio的數據庫項目來管理數據庫，就能夠利用TFS來管理數據庫版本了。具體使用請參考此鏈接：http://msdn.microsoft.com/zh-cn/library/vstudio/dd193266(v=vs.100).aspx
使用VS數據庫項目具有如下優點：
l 支持版本管理
l 便於團隊協作開發
l 支持對不能版本數據庫進行部署
l 支持生成測試數據
l 提供了許多額外的功能與工具：數據庫架構比較、數據比較、生成腳本等
8. 將必要的附屬文件集成到源代碼管理
這是特別重要的一點。當應用程序需要外部的附屬文件存在才可以正常運行的話，把那些文件也都放進源代碼管理軟件里！人們傾向於犯的錯誤是，在他們擁有自己設置文件和本地附屬文件的環境里一切都表現得很好就把東西都上傳了，之后覺得沒問題了就不管了。但是其他人不能從源代碼庫里找到同樣的附屬文件的話，所有東西都會悲劇性地報錯。
比如，通常我們的項目會引用很多第三方的dll，那么就應該將這些dll都集成到源代碼管理，如圖：
最后
- 本篇文檔Word版下載地址：TFS源代碼管理的8大注意事項.zip。
- 本文參考了《源代碼管理十誡》，並做了一些修改。
- 希望大家積極討論並補充。