在Xcode中使用Git進行源碼版本控制 在應用程式開發過程中，很重要的一部分工作就是如何進行源碼的版本控制。當代碼出現問題時，我們就需要將代碼恢復到原先正常的版本。如果是多個人共同開發一個項目，那麼代碼的控制就會非常複雜。幸運的是，開發者不需要自己控制這些，因為有專門的軟體來負責，叫做版本控制系統 ...
在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方法：
| 1 2 3 4 5 6 7 8 9 10 11 12 |
- (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這個分支開發，這其實不是一個好習慣。無論你是單打獨鬥還是組團合作，我認為在對項目作出重大改變或添加重大功能時，使用分支是十分重要的，它會為你避免很多麻煩。當然，在團隊項目中，為你自己負責部分的代碼搞一個分支幾乎是必須的。
關於分支，你必須記住以下兩點：
-
提交到App Store或客戶的最終產品必須是項目中的master分支項目。
-
任何在第二分支中實現的代碼或者功能最終都必須合併到master分支，這樣正式發佈的應用程式才是完整的。（以後再講這一點）
當你開始一個新分支時，你實際上是以當前工作狀態作為起點，即使你有任何未提交的更改。從這個時候起，所有的改變都會只體現在分支中。
現在讓我們回到Xcode，要創建一個分支，點擊Source Control > GitDemo-master > New Brance…這個菜單，然後會彈出如下菜單：
為這個分支起一個名字，我就把它起名為AnotherBranch好了。現在你怎麼給它起名其實都無所謂。點擊OK按鈕，等一下新的分支就會被創建，而當前的代碼也會複製到新分支中去。
打開Source Control菜單，你就可以輕鬆地找出活動分支是哪一個：它就在項目名字的旁邊。
現在，讓我們做一次新的分支的提交。在這之前，讓我們添加一些新的代碼。打開類文件，在私有屬性區添加以下方法聲明：
@interface ViewController () ... -(void)sayHello; @end
然後實現它：
| 1 2 3 |
-(void)sayHello{
NSLog("Hello");
}
|
最後，在viewDidLoad中調用它：
| 1 2 3 4 5 6 |
- (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
然後實現它：
| 1 2 3 |
-(void)sayByeBye{
NSLog("Bye - Bye");
}
|
最後，在ViewDidLoad方法中調用它：
| 1 2 3 4 5 6 |
- (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 ，添加一個公共方法聲明：
| 1 2 3 4 5 |
@interface ViewController : UIViewController
-(void)aVeryCoolMethod;
@end
|
現在，讓我們在ViewController.m中添加一個這個方法的實現，簡單點就行：
| 1 2 3 |
-(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。我想再重申一下，如果你是一個團隊在工作，使用版本控制工具是必須的！如果你是單打獨鬥，使用版本控制工具也是很有必要的，它可以為你花大量時間和精力所做的工作提供保障，並且在你添加新功能時可簡單地進行擴展。這個工具就像有些人說的那樣，一旦用了，就再也回不去了！最後，我希望這個教程會對你有用。
