在Xcode中使用Git進行源碼版本控制，xcodegit

在Xcode中使用Git進行源碼版本控制，xcodegit
在Xcode中使用Git進行源碼版本控制

在應用程式開發過程中，很重要的一部分工作就是如何進行源碼的版本控制。當代碼出現問題時，我們就需要將代碼恢複到原先正常的版本。如果是多個人共同開發一個項目，那麼代碼的控制就會非常複雜。幸運的是，開發人員不需要自己控制這些，因為有專門的軟體來負責，叫做版本控制系統。

版本控制系統，或者說修改控制系統，實際上是一種檢測源檔案的改變並將其儲存留作以後參考使用的機制（軟體）。此外，它還能記錄其他有用資訊，比如是哪個開發人員修改了代碼，何時修改的，修改了哪一部分，以及其他曆史資訊。版本控制系統可以比較不同版本代碼的不同，有必要時能恢複整個項目到以前的版本，追蹤有害代碼從而減少產品的錯誤。

通過版本控制系統，開發人員可以在一個項目的不同分支上工作，當項目的各個部分開發完備時，將它們放到一起形成最終的版本，這個過程被稱為合并。事實上，這種做法再團隊和軟體公司中相當常見：每個人負責項目的一部分，最終所有部分被整合到一起形成最終產品。

對於個人開發人員來說，版本控制系統並不是必需的，但是我們仍然強烈推薦開發人員使用它，因為它可以使代碼方便的在有錯誤的版本和可以工作的版本之間轉換。事實上，很多開發人員從來不使用類似的工具，他們會在項目添加新的功能時手動儲存原先的項目。這其實是一個很不好的習慣，因為版本控制軟體可以更好更高效地完成這項任務。

Git是一個常見的版本控制系統，它最開始是由Liunx之父Linus Torvalds開發的，Git使用虛擬目錄，又稱為repositories，來管理一切事物。Git可以通過命令列調用，也有專門為它設計的案頭應用軟體。如果Git對你來說很陌生，我建議你在網上查看一些它的相關資訊。關於Git更深層次的內容都不在本文的討論範圍之內。

從Xcode5開始引入了使用git的一些新特性。它將git的各項功能整合到一個菜單中，並提供子功能表來進行軟體合并的控制。在接下來的閱讀中你會發現，使用git來進資料列版本設定相當的簡單快捷。

我們接下來的任務就是學習如何在Xcode中使用git，以及Xcode是如何整合Git的各項功能。如果你覺得對這些很陌生，我建議你先上網搜尋一下相關的內容。在接下來的教程中，我會假定你已經瞭解了版本控制系統和git是什麼，並將注意力集中在Xcode如何管理它上。

GIT Demo概述（GIT Demo Overview）

與其他教程中的demo app不同，這次我們不會去實現一個應用來示範某一項iOS SDK特性，最終我們也不會產生一個樣本產品。實際上，我們會建立一個demo工程，寫幾行代碼，然後利用這個工程來示範Xcode提供的版本管理功能。換句話說，我們會集中注意裡於IDE上，而不是iOS本身。

我建議你跟著我一起一步一步實現這個執行個體項目，在相應的地方手動添加代碼，不用擔心，代碼量不是很多。跟著教程的步驟，我們將執行多種重複的版本控制相關的操作，並且我們必須即時看到結果。如果我只是提供了一個具備所有操作的的應用，那麼你無法體會到這些改變。

好了，廢話不多說了，讓我們仔細看看使用Xcode進資料列版本設定的要點吧。

建立一個Git源（Creating a Git repository）

每次在Xcode中建立新工程的時候，都會提示開發人員是否將項目作為一個本地的git源。在建立工程的最後一步Xcode會有一個複選框，如果選擇了它，git源就會被添加到工程目錄中。通常這個選項會被忽視，或是被認為是Xcode的另外一個沒用的功能，尤其是從未用過git的開發人員，或是編程新手。

開啟Xcode，建立一個新的工程。選擇iOS區的“Application”，在應用模板頁選擇“Single View Application”。

選擇下一步，在項目名中輸入GitDemo，確保下面的Devices菜單選擇iPhone，無需iPad或者universal app。

點擊下一步，也就是最後一個步驟，在這裡先選擇一個要保持工程的目錄，然後在視窗底部選上Create git repository on (My Mac ):

預設情況下，這個選項是被選上的，如果你不想使用git，你可以取消它，但是我不建議這麼做。本教程中，你需要將它勾選上，然後點擊建立按鈕。

建立完項目之後，開啟Finder，找到項目儲存的目錄，在目錄中，有一個.git的子目錄，時Xcode為儲存git源相關資料自動建立的。

如果你看不到.git目錄，你需要讓隱藏的檔案可見。具體做法就是開啟一個Terminal視窗，輸入以下命令：

對於OS X Mavericks 10.9:

defaults write com.apple.finder AppleShowAllFiles TRUE

對於以前的OS X版本，

efaults write com.apple.Finder AppleShowAllFiles TRUE

為了重啟Finder應用，輸入

killall Finder

這就是本項目在本地git源儲存的位置。實際上，如果你選上了相應的選項，這個目錄就會被建立。相應地，在你建立新應用時，.git子目錄也會一同被建立。

顯然使用Xcode建立一個git源毫不費力，然而，如果你在項目建立時未建立git源，之後又想加上這個功能怎麼辦呢？好吧，其實你可以在任何時候為你的項目建立源，但是不是使用Xcode。儘管這種情況很少發生，我還是會告訴你該怎麼做。

如果你願意的話，你可以直接跳到本教程的下一部分。我建議你接著讀下去，因為接下來這些資訊還是很有用的。

在進行示範前，你需要首先通過Xcode下載Command Line Tools，因為我們要在Terminal下操作，並且需要一些額外的工具。如果你還沒有下載，那就去Xcode>Preferences…菜單，選擇Download選項卡，展開Components區，點擊Commond Line Tools右邊下載按鈕。下載完成後，一個對勾符號會取代下載按鈕。

 

現在，為這個例子再建立一個工程，完事後可以刪了它。在建立時取消那個建立git源的選項。這次我們不想讓Xcode為我們準備一個源。把這個工程命名為NoGitExample，儲存到案頭，然後你可以跟我接下來輸入的命令一樣。

一切準備妥當後，開啟Terminal視窗（如果你之前開啟了一個，那就先關掉它再重啟，從而使我們安裝的命令列工具生效）。下面切換到新項目的目錄：

cd /Users/YOUR-USERNAME/Desktop/NoGitExample

別忘了在上邊命令中設定Mac的使用者名稱，接下來，輸入：

git init

 這會初始化一個空的源，如果你在Finder裡面查看或是輸入ls命令，你會看到.git子目錄已經被建立，很好，接下來輸入：

git add .

這樣，目前的目錄所有的內容就被添加到源裡面去了，最後，輸入以下命令：

git commit -m 'Initial commit'

接下來會出現一個本地git源所執行的改變列表，如所示：

現在git源就建好了，但是如果你回到Xcode，開啟Source Control菜單，你會發現一切仍然是被禁用。

這是因為當我們使用命令列工具建立git源時，Xcode並未被通知，下面點擊Xcode>Quit Xcode，然後重新啟動它，在NoGitExample項目中，如果你再次開啟Source Control菜單，你會發現所有的選項已經被使能了，就像一開始勾選上建立git源一樣。

現在這個項目的使命已經結束，你可以在案頭上刪除它。

現在你知道如何為你所有的項目添加git源了，即使你在建立時沒有添加，你也可以在以後任何時候為它手動添加源。

提交更改（Committing Changes）
提交更改指的是儲存一個包含所有更改的新版本。一般來說，當我們做了一些有意義的工作，並且項目處於某一個穩定點時，就可以提交一次更改。然而具體什麼時候提交更改並沒有硬性的規定。我的建議是：從上次提交更改之後，如果你怕花費大量時間和精力做的新工作被誤刪很難恢複，你就需要提交更改了。

預設情況下，Xcode在項目建立之初會提交一次更改，這是為了儲存項目初始狀態。這項工作會在後台完成，不會打擾你或者要求你進行確認。如果你在項目建立時沒有添加git源，但是之後你手動添加了，你可以通過我們先前使用過的命令來進行提交：git commit -m ‘Initial commit’

實際上，你如果去Source Control>History…菜單，你就會看到初次提交更改的記錄，以後每次提交更改，都會在這裡有所記錄。

接下來讓我們小幅修改一下我們的工程，在ViewController.m檔案中，添加以下屬性聲明：

@interface ViewController ()   @property (nonatomic) int sum;   @end

接下來，像下面這樣修改viewDidLoad方法：

123456789101112

- (void)didReceiveMemoryWarning{    [super didReceiveMemoryWarning];    // Dispose of any resources that can be recreated.      int a = 5;    int b = 10;      self.sum = a + b;      NSLog("The result is: %d", self.sum);}

看一下Project navigator面板，你會發現在ViewController.m檔案旁邊，添加了一個M字母，像下面這樣：

這意味著那個檔案已經被修改，相比上一次提交更改，檔案有所改變。一般來說，你每次改變檔案，都會出現這個M字母，提醒你有未認可的變更。

下面看看如何提交更改，其實非常簡單，只需要開啟Source Control>Commit菜單，下面視窗就會出現：

讓我們一步步看看它告訴我們了什麼。在左邊（標1的地區），列出了所有被更改的檔案，在這個例子中，只有ViewController.m這個檔案被改變，因此列表中只有它被顯示。如果你仔細觀察，你會發現檔案左邊有一個選擇框，預設情況下是被選中的，如果你取消它，這個檔案的更改就不會被提交。

在視窗的中間地區，有兩個預覽視窗，左邊那個是檔案目前的版本，右邊是檔案上一次提交更改的版本。因為我們目前只是建立時提交過一次更改，因此右邊顯示的是檔案的初始狀態。

左邊視窗藍色地區標出的就是更改的內容，這樣的表示讓我們可以清楚地看出所有的修改。如果你仔細看，會發現在兩個視窗之間還有一個帶數位小標籤，這個數字一一表示了各項更改。在數字旁邊，預設情況下有一個小對勾，表示本更改會被提交，如果你點擊右邊的小箭頭，會彈出一個選項菜單，你可以選擇不提交這個更改或是忽略它。

 

如果你選擇了Don’t Commit這個選項，小對勾就會被一個停止標誌取代，這項更改就不會被儲存到源中。

如果你選擇了Discard Change這個選項，會彈出一個確認視窗，提示你所做的更改會被恢複，並且無法取消這個操作。

如果你點擊了OK按鈕，所選地區的改變就會消失，就像他們從未出現過一樣。

如果你仔細觀察上面這個提交視窗，你會看到你所做的所有修改都會被Xcode看做改變，即使是一個空行。實際上空行相當於斷行符號，在螢幕上是不可見的，因此作為改變也是理所當然的。

在本例子中，你不用忽略任何修改，而是允許提交所有更改，因此所有的改變標籤旁邊必須都是小對勾。

在兩個視窗下面是一個空白的地區，中間顯示了提交更改的資訊。這個地方可以添加一些關於此次更改的簡短描述，點擊它，加入如下內容：

書寫有意義的提交資訊非常有用，尤其是當你頻繁提交的時候。因此，把它當做一個必要的步驟。

現在這個視窗的基本資料看的差不多了，是時候做我們第一次的提交了。在這個視窗的右下腳，有一個按鈕上面寫著：Commit 1 file。

這個按鈕會顯示需要提交的檔案總數。點擊它之後你的第一次提交就完成了！開啟Source control > History，你會發現它會被顯示在列表中。

從中可以看出，我們編寫的資訊以及更改的檔案數量會被顯示出來。Xcode執行初始提交，所有檔案都會被提交一下，而這次只有我們修改的那個檔案被提交。

另外，關閉曆史視窗，看一下Project Navigator，你會發現ViewController.m旁邊的M符號已經消失了。

現在，讓我們準備下一次提交。這次，我們給工程添加一些新的檔案。添加檔案最好的方式就是建立個新類，因此，按下Command+N按鍵組合，添加一個Objective-C類。讓這個類繼承NSObject類，取名叫TestClass，然後添加到工程中。

完成之後，注意一下Project Navigator，你會發現兩個新的類檔案旁邊有個A的字母標識，這意味著這些檔案已經被添加到項目中，當然，他們還沒有被提交。

開啟ViewController.h檔案，匯入我們的新類：

#import "TestClass.h"

下一步，開啟ViewController.m檔案，像下面一樣聲明一個私人屬性：

@interface ViewController ()   @property (nonatomic) int sum;   @property (nonatomic, strong) TestClass *testClass;   @end

看一下項目導覽列，這次有四個檔案有待提交。讓我們開啟Source Control > Commit菜單，將它們提交。

需要提交的一共有5個檔案。除了之前修改的四個之外，還有一個項目設定檔。Xcode會在新類被添加到項目中之後自動修改這個檔案。如果你你開啟TestClass.h或TestClass.m檔案，左邊的視窗沒有任何顯示，如所示。

這是因為在這個檔案在之前沒有被提交的記錄，因此沒有一個可以比較的版本，在右邊只顯示了File was added。

在訊息區寫上這樣一個描述：TestClass was added to project.. 之後點擊Commit 5 files按鈕即可。

這樣第二次手動提交就成功了。你可以到Source Control > History 菜單查看提交的記錄。

版本之間的比較（Comparing Versions）
當你提交了同一工程的不同版本之後，在他們之間比較，追蹤修改資訊就會非常方便。當新添加的代碼不能運行時，這時與之間版本進行比較就非常重要了，你可以看出新版本相比上個穩定版有了哪些更改。

要比較同一個檔案的兩個版本，你可以使用View>Version Editor>Show version editor，或是點擊工具列上的Version Editor按鈕：

點擊之後，編輯器會分為兩欄。最初，兩欄會顯示相同的內容，點擊編輯器下面的那個小時鐘表徵圖，可以選擇之前已經提交的版本進行比較。

點擊之後，兩個版本的區別會在編輯器中顯示出來。通常，左邊顯示的是目前的版本的檔案，右邊顯示的是之前的版本。藍色高亮的地區顯示了被更改的代碼，因此比較代碼的變化非常容易。繼續選擇任何此前的版本，並觀察兩欄的區別。

你可能會注意到，在兩個編輯器中間，還有在提交視窗看到的小標籤。點擊向下的按鈕可以跳出讓你忽略更改的選項。如果你點擊了忽略更改，Xcode會提示你是否同意。如果你同意忽略，這些被忽略的代碼將會永遠消失，無法再找回來。所以要注意不要無意中忽略任何代碼。

除了上面說到的方法，還有一種你回到之前版本的方法。如果你仔細觀察兩個編輯器下面的工具列，在中間有個帶箭頭的時鐘表徵圖：

點擊它之後，兩個面板之間的縱列內容就發生了改變，變成了一系列表示之前更改的時間戳記。注意並不是所有的都代表實際提交。代表先前版本的圓角矩形的數量取決於提交的次數。在這個例子中，只有兩個這樣的圖形，代表了兩次提交。

在這一列的下面，有兩個箭頭。左邊的那個屬於左邊的面板，右邊的箭頭屬於右邊的面板。將箭頭移動到任意之前的版本，你會看到在相應面板中的改變。如果你想比較目前的版本和之前任意版本的區別，讓一個箭頭指向local行，然後移動第二個箭頭。時間戳記從底部到頂部代表了從新到舊的代碼。在base行，你會看到上一次提交的內容。繼續向上移動，你會看到最初的提交，如所示：

現在你知道如何比較版本之間的區別了。再繼續深入之前，把前面學習的練習一下玩玩吧。

究竟是誰的錯？（Who’s Got the Blame）
除了比較檔案的版本外，Xcode還可以讓你追蹤檔案的提交者，以及是誰改變了哪一部分代碼。在一個多人的團隊中，這非常有用。要使用這個功能，點擊View > Version Editor > Show Blame View菜單。或是講滑鼠放在工具列的Version editor 按鈕上，選擇Blame選項。一個與上面類似的視窗將會出現:

正如你看到的，當前檔案依據不同的提交被水平線分成幾段，每個程式碼片段的作者，以及提交資訊和其他資訊顯示在視窗右邊的一個特殊面板中。

如果你還沒有做過，那自己動手開啟這個blame視圖，注意一下Xcode展現程式碼片段作者的方式。在這個視圖中，可以方便地找到某一代碼在何時被誰提交以及其他你想要的資訊。將滑鼠放在blame面板上，將會顯示修改的一些其他資訊。當指標停在提交段上時，一個帶圖片的小按鈕就會出現在它的右邊。點擊選中該段代碼，就會彈出一個附帶提交資訊視窗。在這個視窗中，你還可以跳轉到比較視窗(indication #1)，以及特定提交的修改檔案(indication #2)。

 

除了比較視圖和blame試圖，其實還有一個日誌視圖（Log view）。你可以通過View > Version Editor > Show Log View來開啟它。或者如果你在這裡就不在詳細說它了。你可以自己去看看，畢竟這個用起來也沒那麼複雜。

分支（Branches）
試想一下，你現在的工程有一個即將發布的版本，或是已經發布的版本，你突然想添加一些新的特性，如何防止這些新添加的代碼讓整個項目陷入癱瘓呢？答案很簡單：你需要使用分支。

如何簡單的理解分支呢？你可以把你的項目想象成一棵樹，穩定版本就是樹的主幹。任何添加新功能的版本都必須是樹榦的一部分。分支，就像是樹的枝幹，它從樹榦生長出來，向不同的方向生長。在git中，你可以通過建立分支來為你的代碼設定一個新的路徑來實現新特性，而不用擔心在開發中破壞主幹。

實際上，在git中預設都會有一個分支，叫做master。Xcode自動執行的第一次提交中就發生在這個分支中。通常，單獨的開發人員只在master這個分支開發，這其實不是一個好習慣。無論你是單打獨鬥還是組團合作，我認為在對項目作出重大改變或添加重大功能時，使用分支是十分重要的，它會為你避免很多麻煩。當然，在Team 專案中，為你自己負責部分的代碼搞一個分支幾乎是必須的。

關於分支，你必須記住以下兩點：

• 提交到App Store或客戶的最終產品必須是項目中的master分支項目。

• 任何在第二分支中實現的代碼或者功能最終都必須合并到master分支，這樣正式發布的應用程式才是完整的。（以後再講這一點）

當你開始一個新分支時，你實際上是以當前工作狀態作為起點，即使你有任何未認可的變更。從這個時候起，所有的改變都會只體現在分支中。

現在讓我們回到Xcode，要建立一個分支，點擊Source Control > GitDemo-master > New Brance…這個菜單，然後會彈出如下菜單：

為這個分支起一個名字，我就把它起名為AnotherBranch好了。現在你怎麼給它起名其實都無所謂。點擊OK按鈕，等一下新的分支就會被建立，而當前的代碼也會複製到新分支中去。

開啟Source Control菜單，你就可以輕鬆地找出活動分支是哪一個：它就在項目名字的旁邊。

現在，讓我們做一次新的分支的提交。在這之前，讓我們添加一些新的代碼。開啟類檔案，在私人屬性區添加以下方法聲明：

@interface ViewController ()   ...-(void)sayHello;   @end

然後實現它：

123	-(void)sayHello{    NSLog("Hello");}

最後，在viewDidLoad中調用它：

123456

- (void)didReceiveMemoryWarning{    ...          [self sayHello];}

現在，點擊Source Control > Commit菜單，版本比較視窗將會出現，你會看到只有一個被修改過的檔案--ViewController.m檔案，新添加的部分會被高亮顯示。

輸入下一個提交資訊：First commit to a new branch，然後點擊commit 1 file按鈕。現在AnotherBrance分支的改變就會被提交了。

開啟Version Editor(menu View > Version Editor > Show Version Editor)，找到右邊編輯面板下面的工具列，你會看到被選中的分支是AnotherBranch，點擊它，你會看到這個分支和master分支同時出現，從master分支中選擇任意版本，Xcode都會高亮顯示兩者之間的區別。通過這樣，你可以方便地跟蹤所有分支間代碼的改變。

最後，切換到另一個分支，或是master分支，你可以點擊Source Control > GitDemo –AnotherBranch > Switch to Branch…菜單。

從這個視窗你可以選擇想要跳轉的分支，在這裡讓我們跳回master分支：

選擇它並點擊Switch按鈕，master分支就會成為當然活動分支。你會發現在AnotherBranch中做出的改變並沒有出現在master分支。很好，我們在管理工程推進的同時，卻沒有修改穩定版本。

合并分支（Merging Branches）
在分支中進行開發是一種好習慣，然而，如果代碼改變要體現在發行版中，那麼分支就必須被合并到master分支中。這一節我們將會告訴你怎樣合并它們。在Xcode裡，將兩個分支合并成一個非常簡單。

讓我們做一個小實驗來看看合并是怎樣工作的。首先，確保master分支是現在的活動分支。如果不是，趕緊改過來：Source Control > GitDemo – AnotherBranch > Switch To Branch… menu，並從展示視窗選擇master分支。

下一步，建立一個新的分支：Source Control > GitDemo – master > New Branch… menu，命名為LastBranch

先讓Xcode飛一會，然後，到ViewController.m檔案中，再建立一個私人方法，首先聲明它：

@interface ViewController ()   ...    -(void)sayByeBye;   @end

然後實現它：

123	-(void)sayByeBye{    NSLog("Bye - Bye");}

最後，在ViewDidLoad方法中調用它：

123456

- (void)viewDidLoad{    ...          [self sayByeBye];}

在合并之前，先提交這些更改。使用Source Control > Commit菜單來執行提交。

終於還是來到這一步，關於把兩個不同的分支合并成一個，你有兩種選擇：

• 從分支合并：與你選擇的分支相關的任何改變都會被合并到現在活動分支中。

• 合并到分支：當前活動分支的任何改變都會被合并到你選擇的分支中。

這兩種方式你都可以在Source Control > GitDemo 菜單中找到。注意當你的活動分支是master分支時，第二個選項是不可選的。

假設一個開發人員在Anotherbranch分支實現一個sayHello方法，另外一個開發人員在LastBranch中建立實現了sayByeBye方法，現在你需要將兩個人的工作合并到下一個穩定版本中，想一想你需要怎麼做？很簡單，按以下方法將改變從兩個分支中合并進來：

首先，確保當前活躍分支是master分支。

然後，開啟Source Control > GitDemo – master > Merge From Branch…菜單，選擇AnotherBranch然後點擊Merge按鈕。

接下來會出現一個比較視窗，在裡面你會看到合并之後代碼的更改，看一眼，感覺差不多了就再點擊Merge按鈕。

Xcode會詢問你是否儲存項目的快照，點擊Enable按鈕。讓Xcode飛一會，然後就好啦。AnotherBranch裡面添加的內容已經合并到master分支中。

使用同樣的方法來合并LastBranch。你會發現如果你不提交更改，Xcode不會讓你再次合并。於是，我們只好先提交一下。在比較視窗你會發現一個紅色的地區顯示合并之後的更改，而不是之前的藍色。這意味著分支中的代碼將會替換原先活動分支中的代碼。

你可以輕鬆地避免這種現象的發生。在編輯面板的下面有幾個小按鈕，你可以試試他們都有什麼作用，我選了第一個，它的意思是master分支的代碼會被放在上面，另一個分支的代碼會跟在它後面。

處理接下來所有需要更改的代碼，不要有遺漏。完事後就點擊Merge按鈕。

恭喜你！你已經成功的學會從多個分支合并了代碼，類似的情形你也應該會了。

忽略更改（Discarding Changes）
放棄不想要的代碼更改功能非常有用，只需輕輕一點，自從上一次提交之後的更改都會被放棄。當你在開發過程中發現出了大亂子，你想從上一個穩定點重新開始時，這個功能就派上用場啦。注意捨棄變更這個功能沒有回頭路，點完之後你就沒有辦法再撤銷這個操作，所以，要小心使用啊！

之前，當我們在討論版本比較時，我們學會了如何忽略某一部分更改的方法，下面，我們要學一下如何一下忽略自從上一次提交之後的所有更改。

為了測試這個功能，首先寫一些代碼開啟ViewController.h ，添加一個公用方法聲明：

12345

@interface ViewController : UIViewController  -(void)aVeryCoolMethod;  @end

現在，讓我們在ViewController.m中添加一個這個方法的實現，簡單點就行：

123	-(void)aVeryCoolMethod{    NSLog("I'm feeling that you'll discard me... Really?");}

如果你注意到Project Navigator，我們剛剛更改的檔案旁邊有了一個M標識，很好，我們想看看如果忽略這些更改，這些檔案是否會回到更改之前的狀態。

這裡有一個重要的細節：你可以選擇忽略所有檔案的更改，也可以選擇忽略單個檔案的更改，這完全取決於你。如果你想忽略一個檔案的更改，首先選定這個檔案。在這個例子裡，如果你只選擇ViewController.m檔案然後開啟Source Control菜單，你會在ViewController.m中發現Didcard Changes這個選項。類似的，如果你只選擇ViewController.h也是一個道理。然而，如果你想忽視這兩個檔案的更改（這裡假定有兩個以上的更改），就在Project Navigator中選中它們，然後再開啟Source Control菜單。相應的位置就會顯示Discard Changes in 2 Files，像下面這樣：

然而，這次我們不會使用這個按鈕，我們要用Discard All Changes。點擊它之後，一個確定提示框就會出現，這是這部分Xcode防止你誤刪代碼的唯一措施。

點擊Discard All Changes, 那你剛才寫的那個公用方法就永遠屬於過去了。看到了吧，只需幾步就可以讓你從當前工作狀態恢複到之前的提交，所以我再一次提醒你要在使用Source Control 中小心點，別誤點了這個按鈕。

總結
通過這篇教程，我儘力詳述了在Xcode中進資料列版本設定的方法。其實在幕後，真正起作用的是git----地球上應用最多的版本控制系統。你可能注意到我在教程中並沒有過多的提到GitHub或者任何Xcode的一些功能----其實我是故意這樣的。我想把注意力集中在使用Xcode進行git管理的內容上。只有當你懂得了如何進資料列版本設定之後，才能真正的使用GitHub。我想再重申一下，如果你是一個團隊在工作，使用版本控制工具是必須的！如果你是單打獨鬥，使用版本控制工具也是很有必要的，它可以為你花大量時間和精力所做的工作提供保障，並且在你添加新功能時可簡單地進行擴充。這個工具就像有些人說的那樣，一旦用了，就再也回不去了！最後，我希望這個教程會對你有用。