源碼管理--llorch的Visual Studio基本教程（四）

通用的演示樣例說明：

• 本系列博客僅僅討論工具的基礎，不討論不論什麼語言。
  • 甚至不討論快捷鍵:-)
  • 可以用鼠標就完畢本教程
• IDE默認指代的是Visual Studio 2013 Community Edition。

  本系列文章的結尾，你可以熟練地使用它敲代碼。

• 將Visual Studio啓動後的默認佈局狀態稱爲主窗體,主窗體標題欄中顯示的項目名稱沒必要要。

• 在平常口語和Windows資源管理器的基礎上定義了幾個描寫敘述菜單操做的符號：[]、{}、/、>>、=、(,)。
• 檢查一個設置項的表示方法爲:
  • [窗體名稱]/{菜單名稱}/{子菜單名稱}/{設置項項名稱}=設置項的值
• 好比默認的Debug配置:
  • [主窗體]/{解決方式配置管理器}=Debug
• 檢查多個設置項時，依照單個設置項的方式，逐一寫出
• 檢查一個設置項有多個值的時候，用括號包含並用內部的逗號分隔，如:
  • [解決方式資源管理器]/{項目名稱}/{引用}=(System,System.Core,System.Data,System.Xml)
• 運行一個左鍵單擊序列，就是將最後的檢查項換成」/」。好比退出IDE:
  • [主窗體]/{文件}/{退出}/
• 右鍵菜單的鏈接符號爲>>。好比刷新Windows桌面:
  • [桌面]>>{刷新}/
• 彈出窗體中的設置項的表示與上相似
• MDI子窗體中設置項的表示與上相似，注意到在Visual Studio中，MDI子窗體的名稱在它的左上角或者可能本身主動吸附到主窗體的四周
• 標題欄和狀態欄做爲菜單的推廣。適用於上述表示方法
• 缺陷說明
  • 歡迎反饋，mailto:cqwd2010@qq.com
  • 做者的首選語言是C#
  • 做者是軟狗
  • 做者的IDE沒裝中文語言包，因此有的名詞翻譯得不許確:-(
  • 由於尚未釐清相關的證書問題，版權保留
  • 系列文章沒有提出或解決新的問題。目的僅僅是科普

 

正文

這一篇博客討論編程工做內在的目的性，也就是源碼管理。所謂源碼管理只針對可以工做的最穩定的代碼進行管理。笨代碼和聰明代碼是代碼片斷或編程緩存，而非協做中的源碼管理。

 

源碼和代碼片斷

把本身寫過的所有代碼保存起來，是很是好的想法。

把本身能用的代碼保存起來，以便隨時再用。這個想法對開發人員來講，可能會更好一點。因爲後者更能讓開發人員集中注意力於設計。常見的追蹤文件歷史記錄的方式是版本號控制，也就是一般所說的源碼管理。但是一般所說的源碼管理聽起來更像是「字符歷史記錄」。

一片代碼，只從它與程序整體的關係來講，可以概略地分爲兩類，一類是立時可用的，還有一類是「我還要修復一下」的。前一種叫作「源碼」，然後一種只能叫作「片斷(snippets?)」。這個差異對開發者的提示在於。從實踐上說，編程就是環繞release的體力勞動工做。

 

漂亮的代碼和穩定的代碼

漂亮的代碼通常會用一些幽密的手法來實現一個比較bigger的功能。

穩定的代碼則否則。比方求兩個集合的差集的狀況而言。漂亮的代碼可能會在一個循環裏面寫大量的語句，而穩定的代碼則可能寫成三五個順序運行的循環。

那麼。到底是漂亮的代碼好仍是穩定的代碼好呢？

實際上咱們會發現，咱們的確會觀望漂亮的代碼，但咱們賴以發揮做用的仍是穩定的版本號。代碼的穩定的版本號通常會更加easy調試、更加簡約循環的內容。咱們終於會在保持穩定的基礎上進行性能的調整。

 

針對更強的目的性實施源碼管理

至少一個版本號已經在執行。不論是在測試中仍是在原型中。

在此以外談源碼管理就是搞學術研究。

源碼管理的概念應該比項目的層級要高。

這是因爲。就編程的目的而言。一個項目僅僅是達成方案目的的一個子部分。

一旦將源碼管理針對強的目的來進行，那麼源碼管理所維護的重心也就天然而然地落到了工做的完畢時態。

 

用IDE內建的Git進行源碼管理

在Visual Studio中貫穿着強目的性的源碼管理的設計哲學（即便可以很是easy地濫用）。這表現在，在不打開不論什麼解決方式的狀況下。[團隊資源管理器]還是可用的。

而後在分支的合併上有一些本身主動的簡化。

由於實踐所限，llorch眼下還沒實用過Team Foudation Server。所以本篇的內容就以Visual Studio中的Git支持來演示樣例性地說明了。由於Visual Studio 2013內建的Git功能並不完備，有的網友習慣本身組裝其它的Git插件。llorch的教程主要想給新手們提供一點參考，因此，這裏就若是使用第三方插件的是「高級用戶」了。

配置Visual Studio中的Git

[主窗體]/{視圖}/{團隊資源管理器}/。打開[團隊資源管理器]子窗體，這是源碼管理的主要操做窗體。

[團隊資源管理器]/{下拉列表}=設置/{Git設置}/，對影響Visual Studio全局的身份信息、緩存文件夾進行設置。

 

克隆網上的Git倉庫

[團隊資源管理器]/{下拉列表}=項目/{鏈接到團隊項目}/{克隆}/，填入Git倉庫地址和本地緩存文件夾就開始克隆了。

內建的Git工具僅僅能和https協議的公佈URL良好協做。不支持ssh的版本號，而支持Windows憑據登陸的方式。

假設已經克隆過了，這裏的菜單會本身主動切換成拉取。拉取的時最好注意一下分支提交的狀況，以避免覆蓋掉實用的工做。llorch試了幾回。好像僅僅要有分支沒有提交，這裏的拉取就會變灰色。

[團隊資源管理器]/{下拉列表}=項目/{本地Git存儲庫}/{庫N}//，雙擊(//)列出的不論什麼一個本地存儲的庫，會跳轉到[團隊資源管理器-主頁]子窗體，在[團隊資源管理器-主頁]/{解決方式}欄目中可以選擇操做分支或打開解決方式。

一旦打開了解決方式。則手動切換到[解決方式資源管理器]開始編碼。（這是一個用戶體驗上的BUG。沒有本身主動切換過去，可以經過取消團隊資源管理器的停靠來改善。）

 

提交更改到本地存儲庫

[解決方式資源管理器]/{解決方式}>>{提交}/，在當中填入提交消息後就可以提交。

 

提交更改到遠程存儲庫

Visual Studio 2013 Community Edition內建的Git工具僅支持經過https協議向遠程存儲庫提交。

無論怎樣，爲了提升通用性，應該先克隆，改動以後。再提交。

[團隊資源管理器]/{下拉列表}=未同步提交/，假設項目是克隆而來的。那麼直接點擊{傳出提交}/{推送}，可以利用克隆步驟中保存的憑據進行一次提交。假設不是，那麼這裏需要輸入一次憑據。

 

將全新的方案歸入本地Git存儲庫

[解決方式資源管理器]/{解決方式}>>{將解決方式加入到源碼管理}/，呼出[選擇源碼管理]窗體，選擇當中的{Git}。

[解決方式資源管理器]/{解決方式}>>{提交}/，這裏會提交到本地緩存。

提交更改到遠程存儲庫相同是適用的。

 

分支管理

[團隊資源管理器]/{下拉列表}=分支/，在這個界面中Visual Studio把分支的管理簡化到了極致。

基本懂得「分支」是什麼意思的童鞋都應該會使用，就不贅述了。

 

總結

追蹤字符歷史是適用的，而提升目的性更有實際意義。

Visual Studio內建的Git工具只提供了對https協議的支持。而且閹割掉了不少高大上的延展性。然而，假設只就集中精力編寫源碼而言。仍然是適用的。

源碼管理的精髓在於分支與合併。

這多是Visual Studio以外的project。

不建議安裝系統全局的Git工具。最好能用專用的Shell工具（Cygwin、Gentoo-prefix-interix等）來進行高級操做。

這樣不只可以避免額外的複雜性，而且可以較好地控制每用戶環境變量，甚至可以得到不少其它可愛的特性。

得益於Visual Studio強大的插件社區。可以加裝具備完整功能的Git插件。

內建用慣了反而喜歡內建的簡潔。這實在僅僅是個習慣問題

 

ps：llorch寫這一系列博客的目的在於穩固編程技能的基礎。今天的討論是爲了明天能專一編碼。隨着源碼管理的討論陸陸續續寫完，也即將進入尾聲。llorch會以對程序集的討論結束這一系列博客。然後專一於「好玩」的內容上去。

感謝你們的關注和支持！！