理解 XCode 中的 Git 版本控制
在應用程序開發過程中，一個相當顯著的部分是開發人員管理代碼變更的方式。這些是必須包含的功能，存儲和處理工作代碼版本在不同階段穩定階段的副 本，並能夠恢復代碼當存在缺陷或者產生問題的時候。更有甚者，當多個程序員工作在同一個項目時，跟蹤所有的變更是一個單向的路徑。幸運的是，開發人員不必 去發明一種方法來做這些事情，有一個特別的軟件解決方案，叫做版本控制系統（Version Control Systems）
版本控制系統或者叫做修訂控制系統，實際上是一種能夠一直監視代碼文件的變更並存儲他們爲了將來引用的機制（軟件）。除了這些之外，版本控制系統也 保存了額外的必要數據，例如哪個開發人員做了變更，變更發生在什麼時候，實際上修訂了什麼，其他類型的歷史不僅僅是數據。而且，版本控制系統提供了比較代 碼不同版本的功能，如果需要的話，可以恢復特定文件或者整個項目到以前的版本，並追查惡意的代碼最終實現無缺陷產品。
使用版本控制系統，開發人員可以工作在項目的不同路徑上，通常叫做分支（branch），當他們的代碼完成時，所有的代碼將合併到一起以便構建應用 程序的最終發佈版本。這個過程叫做合併代碼（merging），它包含了版本控制系統的一個特殊特性。實際上，在開發團隊和軟件公司中代碼的版本控制是一 個強制性的工作，團隊中的每個人負責項目的一部分，最後所有的代碼被集中到一起放置在一個地方。
對個人開發者來說使用版本控制系統不是必要的，但是仍然是強烈推薦的。一旦遇到嚴重的問題或者說以代碼都亂套了的時候，使用版本控制系統將更容易追 查缺陷或者恢復代碼到穩定版本和代碼的工作版本。事實上，許多的個人程序員，特別是新人，根本不使用版本控制系統，當他們增加新功能或者是修改代碼的時 候，通常手動複製項目的副本。這是一個非常不好的習慣，源碼控制能更好並且更有效率的完成這些工作，同時提供了前面描述的額外功能。
作爲最出名的版本控制系統之一，git由Linux創建者 Linus Torvalds開發。Git在虛擬目錄（倉庫）中組織一切，實際上，任何版本的跟蹤都可以適用於他們。它既可以通過命令行使用，也可以通過桌面應用程序。如果git對你來說很陌生，那麼我建議你在網絡上閱讀一些關於git的文章，而進一步討論git超出了本教程的範圍。
自從Xcode的第五版本起，就集成了git的豐富功能，包括各種選項菜單的按鈕和管理源代碼的子菜單。正像你稍後看到的，使用版本控制git是非常容易和快速的，在你看完本教程之後，沒有理由不使用它。
總結而言之，你已經理解了我們的任務是學習怎樣在Xcode中使用版本控制git，這一切將通過了解Xcode提供的每個相關特性來完成。如果你不 熟悉所有的東西，或者在我們開始之前你需要獲取更多的知識， 請在網絡上搜索相關信息。我不得不說，在本教程中我假設你關於版本控制系統擁有最基本的知識，比如git是什麼，因此我們要把它視爲理所當然的事情，而關 注Xcode怎麼管理這一切。
Git示例演示
與其他教程的演示程序相反，本文中我們不會實現一個應用去展示iOS SDK的具體特性，也不會有一個最終的開發樣本。實際上我們所做的就是去創建一個示例項目，僅僅在幾個點上添加幾行代碼，我們將使用它作爲一個工具去測試 Xcode提供的所有源代碼控制管理選項。換句話說，我們重點討論的是IDE，而不是iOS。
除此之外，這一次不會有可供下載的例程了。取而代之的是，我邀請你一起來一步步實現這個 demo，並且在需要寫代碼的地方手動添加代碼（別擔心，不會很多）。這樣跟下來是有必要的，因爲我們將會重複進行多種與版本控制有關的操作，並且我們必 須即時看到結果。如果我只是提供一個操作已經完成的例程，就不可能有這樣的效果了，因爲這樣下來你自己的練習部分近乎於零。
那麼，讓我們開始吧！我們用 Xcode 來近距離地看一看版本控制系統的精華所在。
創建 Git 倉庫
每次在 Xcode 中創建新項目，都會讓開發者選擇是否要添加一個本地 git repository。新建一個 project 涉及分爲3步的引導過程，其中在第3步也就是最後一步中，Xcode 提供了一個勾選框和相應的說明，如果勾選了，一個 git repository 就會添加到保存 project 的目錄中。這個選項很容易被忽略，或者被當做一個 Xcode 的沒用特性，這種事經常發生，尤其是對於從來沒用過版本控制和 git 的開發者，或者新手程序員。
具體細節如下，啓動Xcode並創建一個新項目。首先，選擇“單視圖應用程序(Single View Application)”作爲應用程序的模板，同時在iOS選項部分，選擇“應用程序(Application)”項。
點擊“下一步(Next)”按鈕到第二步，設定“產品名(Product Name)”字段爲“GitDemo”，同時確保在“設備(Devices)”下拉菜單中選擇“iPhone”。在這裏不需要iPad或者普通應用。
再次點擊下一步按鈕，進入最後一步。在此，首先選擇保存項目的目錄。然後選中窗口的底部的單選框，並選中在“My Mac”上創建git倉庫。
默認情況下，這個勾選框總是被選中的，然後每個 project 都會創建一個 git repo。如果你的項目不想用 git 和版本控制，只需取消選中，但我不建議這樣做。總之，本教程中我們希望啓用git，因此確保你選中了勾選框。最後，點擊 Create 按鈕。
等待 project 創建完成吧，然後打開一個 finder 窗口，來到我們保存 project 的目錄下。在這裏，找到 .git 子目錄，這是 Xcode 自動創建的目錄，用來存儲 git repository 相關的數據。
如果你看不到 .git 目錄，你必須把電腦上的隱藏文件改爲可見。首先，打開Terminal(終端) 窗口，然後輸入以下命令：
對於 OS X Mavericks 10.9:
|
|
defaults write com.apple.finder AppleShowAllFiles TRUE |
對於此前的 OS X 版本:
|
|
defaults write com.apple.Finder AppleShowAllFiles TRUE |
然後，只需重啓 Finder 應用，所以再輸入一條命令：
|
killall Finder |
因此，如你所見，這個 app 的本地 git repository 實際就保存在這裏。相應地，你創建的任何新應用都會隨之帶來一個 .git 子目錄，只要你保持相應的選項是勾選的。
顯然，用 Xcode 來爲 project 添加 git repository 是不費吹灰之力的。然而，如果你在創建 project 時沒有添加 git repository，或者想要稍後再添加，怎麼辦呢？好消息是，你隨時都可以爲 project 添加 repository，但是不用 Xcode 了。儘管這樣的情況很少見，我還是來講解一下。
注意，如果你不想看的話，可以儘管跳過本教程的下一節。但我建議還是讀下去，因爲緊接着再下一節的內容會非常重要。
在開始講之前，你首先需要在 Xcode 裏下載 Command Line Tools ，因爲我們接下來要用 Terminal ，需要一些工具。如果你已經下載了這個包，就進行下一步。如果沒有，要安裝 command line tools，點擊Xcode裏的 Xcode > Preferences… 菜單，然後選擇 Downloads 一項。在窗口的上部，Components 一欄下，點擊 Command Line Tools 右側畫着向下箭頭的按鈕。一旦下載結束，下載按鈕會變成對勾符號。
然後，爲了這個例子再創建一個 Xcode project，我們一切完成之後再把它刪除。這一次確保要取消勾選 Create git repository 選項。在這個例子裏，我們不需要 Xcode 來爲我們準備 repository 了。把這個項目命名爲 NoGitExample，並且保存在桌面上，這樣就能直接使用我接下來的提供的指令了。
一切就緒，打開一個 Terminal 窗口（如果之前已經有打開的窗口，確定要先關閉再重啓，這樣才能應用安裝 command line tools 時做出的改變）。首先，來到保存新 project 的目錄下：
|
|
cd /Users/YOUR-USERNAME/Desktop/NoGitExample |
別忘了把上面的指令改爲你自己 Mac 的用戶名。接下來：
|
|
git init |
這會初始化一個空的 repository。然後如果你打開 Finder 或者在 terminal 輸入 ls 指令，你會看到 .git 子目錄已經創建出來了。太棒了。繼續往下：
|
|
git add . |
用這個指令，當前目錄（點號[.]）的所有內容都會添加到 repository 中。最後，提交全部（也就是持久保存所做的更改）：
|
|
git commit -m 'Initial commit' |
Terminal 窗口中會出現提交到本地 git repository 的文件列表。下圖就是我的terminal的樣子：
git repository 已經準備好了，但是如果你回到 Xcode，打開 Source Control 菜單，你會發現一切都還是不可用的。
這是因爲 Xcode 不會自動被通知到，我們已經手動添加了 git repository。因此，點擊菜單 Xcode > Quit Xcode 來關閉 Xcode ，然後再重啓。現在，在 NoGitExample 項目中，如果你再打開 Source Control 菜單，你會看到這些的選項都可用了，跟我們創建 project 時就添加了 git repository 的效果相同。
到了這一步，就可以關閉這個 NoGitExample 項目，也可以把它從桌面上刪除了。
現在你已經能夠知道怎麼爲一個 project 添加 git repository了。並且即使你在創建 project 時有意或無意沒有添加 git repository，也可以隨時手動添加。
提交更改
說到所謂的“提交更改到 repository”，我們實際的意思是：存儲我們項目的一個新版本。新版本包含目前已作出的所有更改，比如代碼修改或者新添加的文件。一般來說，一次 提交應該發生在一定量的工作已經完成，並且項目處於穩定狀態之時。關於提交的頻率應該是多久一次，並沒有一定之規，但我建議：如果你認爲從上一次提交到現 在之間，你所做的工作如果意外丟失，會造成巨大的時間精力浪費，那就一定要提交一下了。
Xcode 默認會在新項目創建時做一次初始提交，目的是保存一個項目初始狀態的版本。這次提交是在幕後完成的，不會打擾你，也不會要求你確認。如果你在創建項目時沒有添加 git repository，是如前所述在之後手動添加的，初始提交是通過這個指令完成的：git commit -m ‘Initial commit’ 我們之前用過這個指令。
實際上，你可以看到初始提交的相關信息，只需點擊菜單 Source Control > History… 。在這裏記錄了你對項目的每一次提交。
我們現在來嘗試一些操作吧，首先要對項目做點改動。來到 ViewController.m 文件，在 private class 部分添加以下的 property 聲明：
|
1 |
@interface ViewController () |
接下來，修改 viewDidLoad 方法如下：
|
1 |
- (void)didReceiveMemoryWarning |
如果你看一眼 Project Navigator （即左邊欄），你會注意到在 ViewController.m 文件後面，多了一個字母 M，如下圖所示：
這意味着這個文件已經被修改了，並且相比上次提交的版本確實有改動。一般來說，每次你改動一個文件之後，字母 M 就表示已有改動，還未提交。
讓我們來看看怎麼提交代碼。這是很簡單的，僅需要打開Source Control > Commit菜單，如下窗口所示：
一步一步的讓我們看看它告訴了我們什麼。在左邊方框（在圖片中標識爲#1的部分），這兒列出了所有已修改的文件。在我們的例子中，僅僅ViewController.m文件被修改，因此僅僅顯示了一個文件。如果你仔細觀察，你將看到文件的左側有一個缺省選中的複選框。假如你不選中它，已經修改的文件將不會被提交。但是現在這不是我們想要的東西，因此讓它被選中。
在窗口的中間位置（標識爲#2的部分），有兩個預覽框。左側是文件的當前版本（沒有提交的），右側是文件的最近提交的版本。截圖描繪了ViewController.m文件的原始狀態。
左欄的藍色區域（圖中標識爲#3的部分），在右欄變成一條線，這顯示了文件中的實際改動。這樣的表示法讓所有的改動一目瞭然，並且能對應到改動的具體位置 （行號）。也許你注意到了，窗口的中央，在兩個預覽欄之間，有一些小的圓角標籤，上面寫着數字（圖中標識爲#4）。這些標籤一個一個地數出了全部的改動， 上面的數字就是計數的序號。在數字左邊，有一個對勾符號。如果出現了這個對勾，說明對應的改動可以正常提交到 repository。儘管如此，你還是可以選擇跳過，暫時不提交文件的某一個或幾個改動，甚至拋棄所做的更改，只需點擊數字右邊的小下三角。含有兩個選項的小菜單將會浮現：
如果你選擇 Don’t Commit 選項，對勾符號會換成禁止符號，對應的改動就不會提交到 repository 了。
如果你選擇菜單中的 Discard Change 選項，會出現一個確認窗口，提醒你選中的改動將會被回滾，並且回滾是無法被撤銷的。
如果你點擊 OK 按鈕，響應區域中的改動會消失無蹤，彷彿從沒來到世上。
如果你有留心觀察上面的提交窗口截圖，你會發現所有的修改都會被 Xcode 認爲是改動，即使一個空行也不例外。事實上，空行是屏幕上不顯示的換行符，所以它被收集爲一項改動是合情合理的。
總之，對於這個樣例，確保你沒有丟棄任何改動，允許一切都提交。因此你應該看到所有的圓角 label 上都有對勾。
在這兩欄之下是一片空白區域，中間寫着“Enter commit message here”。這個區域用來附加一些簡短信息，描述這個版本所做的更改。點擊它，填上下圖所示的內容：
填寫（有意義的）提交信息至關重要，尤其是在提交次數很多的情況下。所以，要把它當做不可或缺的一步。
既然我們已經瀏覽了一遍這個窗口的主要內容，下面我們來做第一次提交吧。在窗口的右下角，有一個按鈕寫着：Commit 1 file.
在這個按鈕裏，總是會寫着提交的文件總數。點擊它，然後恭喜！你的第一次提交已經誕生，將會永久載入歷史，不僅是你個人的歷史，也是 git 的歷史。這是什麼意思呢？只要打開菜單上的 Source Control > History…，就可以看到它列在這裏。
如你所見，我們之前寫的提交信息以及改動的文件總數都出現在這裏了。在 Xcode 做出的初始提交中，提交了所有文件；但是我們只改動了其中一個。
除此之外，如果你關閉 history 窗口，再看看 Project Navigator 左邊欄，ViewController.m 文件旁邊的 M 字母也消失啦！
現在，我們準備再做一次提交吧。這一次，我們來爲項目添加一些新文件，最好的方式莫過於創建一個新類。那麼，按下鍵盤上的 Command + N 鍵，然後添加一個 Objective-C class。把它設爲 NSObject 的子類，命名爲 TestClass。最後，添加到項目中。
一旦上面這些都完成了，注意左邊欄 Project Navigator 中的兩個類文件旁邊都出現了一個字母 A ；意思是這兩個文件是後添加到項目中的，因此自然它們還沒有被提交過。
打開 ViewController.h 文件，然後 import 我們的類:
|
1 |
#import "TestClass.h" |
接下來，打開 ViewController.m 文件，如下聲明一個 private 屬性：
|
1 |
@interface ViewController () |
再看左邊欄 Project Navigator，注意到現在有4個沒有提交的文件了。兩個類文件是我們剛添加的，還有另外兩個本來就有的文件。我們需要將這些改動也提交，因此打開 Source Control > Commit… 菜單。
這一次，選中了5個有待提交的文件。第5個文件（顯示在第1行）是項目的配置文件，是在添加新類時由 Xcode 自動修改的。如果你點擊 TestClass.h 或 TestClass.m 文件，左（譯者注：原文可能筆誤，此處應該爲“右”）欄會變爲一片空白，如下圖所示：
這是因爲這兩個文件之前沒有提交過，因此沒有之前的版本可以對比。所以，右欄裏只寫着“File was added” 就是再正常不過的了。
來到提交信息區域，填寫提交信息: TestClass class was added to the project。完成之後，點擊 Commit 5 files 按鈕，讓 Xcode 提交更改到 git repository。
第二次手動提交已經順利完成了。可以打開提交歷史來驗證，在菜單 Source Control > History… 中:
版本對比
在你提交了多個版本之後，對比各個版本、跟蹤代碼的變化是非常容易的。當新添的代碼不能如預期工作時，版本對比顯得尤爲重要，因爲你需要找到從上個穩定版本以來的所有變化。
要比較兩個不同版本的文件，或者點擊菜單裏的 View > Version Editor > Show Version Editor，或者點擊工具欄上的 Version Editor 按鈕，如下圖所示：
一旦上面這一步完成，編輯器就會分裂成兩部分。最開始，左、右欄都顯示當前版本的文件。要把任意一欄切換爲某個之前提交的版本，來到這一欄底部的工具欄，點擊最後一個按鈕，上面有時鐘標誌：
一瞬間，選擇的版本對應的差異就顯示在屏幕上了。一般來說，左欄用來顯示當前版本的文件，而右欄用來訪問舊的版本。之前提到過的藍色區域表示了更改的代碼，能輕鬆跟蹤代碼的增加。因此，再往下進行，選擇任意一個之前的提交，觀察兩欄顯示出的差異。
你應該注意到，在兩個編輯器的方框之間，有我們在提交窗口中第一次看到的圓形標籤。點擊它們中任意一個向下箭頭，將顯示放棄改變的選項。如果你點擊 它，Xcode會要求你確認，如果你同意了，已經選擇的代碼將永遠的被放棄，沒有任何的機會恢復。因此，要小心，不要放棄任何一片代碼，甚至是在偶然的情 況下。
除了上面介紹的方法，你還有一個方法你可以恢復到以前的版本。如果你仔細觀察兩個方框下的工具條，在它的中間有一個帶時鐘和箭頭的按鈕。
如果你點擊了它，兩個方框之間列將改變並且標籤將被以前提交的一系列時間戳替換。請注意不是他們所有都代表了真實的提交，這取決與提交的總量，圓角矩形的真實數字匹配以前版本的實際數量。例如，在我們的應用程序中在底部僅僅有兩個形狀匹配了真實的提交。
在這一欄底部，有兩個箭頭。左邊的箭頭屬於左欄，指向右邊；右邊的屬於右欄，指向左邊。把這兩個箭頭拖到任何一個歷史版本，你可以立即看到這個版本出現在對應的一欄中。如果你想對比當前版本和任何一個歷史版本，只需讓一個箭頭指向local 一行，然後拖動另外一個箭頭。時間戳的順序，從頂到底是從最新到最舊。這意味着寫着 base 的一行，代表上一次提交的版本；而再往上看，就是那些更老的版本。下圖總結了我剛纔所描述的：
現在你知道如何對比版本，並跟蹤代碼在各個版本的變化了。現在隨便玩一玩這個特性吧，之後我們再往下講。
是誰的責任？
在比較文件的版本之前，Xcode允許追查誰提交了代碼，還有誰修改了那部分的代碼。如果一個項目是多人開發的話，這是一個非常有用的功能。只需簡單地打開視圖View > 文本編輯Version Editor > 展示責任視圖Show Blame View 菜單，或者保持鼠標按鈕在工具欄的文本編輯Version Editor按鈕上，然後選擇責任Blame選項。一個如下圖所示的新窗口就會展示在你面前：
正如你所看到的，被選文件的代碼是根據所提交的人的不同而被水平線分割了好幾部分。根據提交的信息，每一部分的代碼的作者，以及其他相關信息會展現在窗口的右側中的一個特殊的窗格里。
如果你還沒有完成上一步，打開責任視圖，注意看 Xcode 是怎麼用不同提交和不同作者來區別呈現代碼塊的。這樣的界面可以非常快速地定位到某一塊代碼是什麼時間提交，誰提交的，還可以獲得一些額外信息。這些額外信息只要把鼠標移到責任欄上就可以看到。當鼠標放在一個提交片段上時，你可以看到最右出現了一個畫着 i 標識的小按鈕。如果你點擊它，就會選中這段代碼，並彈出一個窗口，上面顯示着全部的提交信息。通過這個窗口，你可以切換到對比窗口（標爲 #1）以及本次提交修改的文件（標爲 #2）。
除了上一節我們看到的對比視圖和剛剛介紹的責任視圖之外，還有一個日誌視圖，可以通過 View > Version Editor > Show Log View 訪問到；或者在工具欄上長按 Version Editor 按鈕，然後選擇 Log 選項。我不再詳細說了，留給你自己試試吧。畢竟，理解日誌是什麼、怎麼用並不難。
分支
想象你的項目有一個可用的版本，準備發佈，或者已經發布了；現在你想開發一個新特性，但又不想意外毀壞了目前穩定可用的程序。在這種情況下，要避免可能的災難性後果，保證你的項目不會被弄毀，你應該怎麼做呢？答案很簡單：用分支。
要清楚理解什麼是分支，可以把你的項目想象成一棵樹，其中樹幹永遠是項目主要的、穩定的、可用的版本。而任何新添加的特性，都必須先成爲樹幹的一部 分，然後才能進入發佈階段。在版本控制系統中的“分支”，就像樹的樹枝一樣，從樹幹長出來，沿着一個不同的方向生長。在 git (最終在 Xcode)中，你可以創建分支來爲代碼開闢一條新路（如實現一個新特性），而不用擔心在開發時會損壞當前可用的版本。
實際上，git 總會默認創建一個分支，名爲 master。Xcode 進行的初始提交，就是在這個分支中進行的。一般來說，單打獨鬥的開發者會只用這一個分支工作，儘管這是個壞習慣。無論你是單獨工作還是在團隊裏，我認爲都 應該在你要做重大改動或添加時使用分支，這樣可以避免陷入麻煩。當然，在團隊合作的項目裏，個人開發的部分幾乎是必須要在一個單獨的分支裏完成的。
記住以下兩點很重要：
1. 提交到 App Store 或客戶手中的最終產品，一定是 master 分支的版本。
2. 任何處於次級分支的代碼或實現的特性，都必須先合併到 master 分支，之後才能被包括進應用的正式發佈（稍後還將談到）。
當你開了一個新分支開始工作時，事實上這個新分支就是從當前的地方開始的，即使還有沒提交的更改也不例外。從此以後，再做出的代碼更改就是隻在新分支上了。
現在回到Xcode。去創建新的分支，到資源控制Source Control > GitDemo – master > 新分支New Branch…菜單，你會看到如下圖所示的窗口：
給該分支取個名。我給它取名爲（正如你在下圖所看到的）AnotherBranch，在這裏你取什麼名它都不會有所不同。然後點擊OK按鈕，等待一段時間直到新分支被創建好，且當前的代碼被複制到該分支上。
你可以很容易地找到你當前活躍的分支是哪個。簡單地打開資源控制Source Control菜單，旁邊的項目名稱的選項那裏就可以看到你當前的分支。
現在，讓我們提交代碼到新的分支。在做這個之前，讓我們增加一些新的的代碼，因此進入私有類區域，增加如下的方法聲明：
|
1 |
@interface ViewController () |
然後，實現它：
|
1 |
-(void)sayHello{ |
最後，在 viewDidLoad方法中調用它：
|
1 |
- (void)didReceiveMemoryWarning |
現在，切換到 Source Control > Commit菜單，將顯示版本比較窗口。你將看到僅僅一個已修改的文件 ViewController.m將要提交，並且新增加的代碼高亮顯示。
提交代碼並且增加如下的提交信息：第一次提交到分支，然後點擊Commit 1 File按鈕。改變將發生在AnotherBranch分支
打開版本編輯器（菜單視圖 View > 版本編輯器Version Editor > 顯示版本編輯器Show Version Editor），然後再到右邊編輯窗口下面的工具欄中。你會看到被選擇的分支是AnotherBranche。點擊它，這時候該分支和主分支都會出現。從主分支上，選擇你想要的任何一個版本，Xcode就會把AnotherBranch分支上的當前版本和主分支上被選擇的版本之間的變化高亮出來。採用這種方式，以及我們之前的教程所談到的比較版本部分的內容，你都可以很輕鬆地追蹤到你工程中所有分支之間代碼的變化。
最後，切換到另一個分支，或者主分支，進入資源控制Source Control > GitDemo – AnotherBranch > 切換到另一個分支Switch to Branch… 菜單：
從出現的窗口中，選擇你想切換到的分支，在我們這個例子中選的是主分支：
選擇它並點擊切換Switch按鈕。主分支就會再次變成當前活躍的分支，你會發現那些只有在AnotherBranch分支中所做的變化都不會在這裏出現。這很棒，因爲我們能夠成功地推動我們的工程，而不需要修改穩定的版本。
合併分支
在主分支以外的分支上工作，這在執行狀態中是很好的習慣。然而，如果任何代碼的添加或者修改都意味着要在應用程序下一個版本中出現的話，這就必須放到主分支上，所以在這一部分，我們將會看如何完成這項任務。正如標題所總結的一樣，我們談論的這部分功能就叫合併，以及Xcode提供的一種快速合併兩個分支版本的方法。
讓我們做一個小實驗來看看如何合併工作。首先要確定你現在處在主分支上。如果不是，請到資源控制器Source Control > GitDemo – AnotherBranch > 切換到另一個分支Switch To Branch…菜單中，並在彈出窗口裏選擇主分支。
接着，用資源控制器Source Control > GitDemo – master > 新建分支New Branch… 菜單創建一個新的分支，取名爲LastBranch。
給Xcode一點時間去準備。現在，在ViewController.m文件中創建一個或多個假的私有方法，並聲明它：
|
1 |
@interface ViewController () |
然後實現它：
|
1 |
-(void)sayByeBye{ |
最後，在viewDidLoad方法中調用它：
|
1 |
- (void)viewDidLoad |
在合併之前，該分支上做的修改必須先提交到本地倉庫。因此，在資源控制器Source Control > 提交Commit...去執行提交。
言歸正傳。合併兩個不同的分支到一個分支上，你有兩種選擇：
-
從分支上合併Merge From Branch: 你可以選擇在分支上做過的任何修改來合併到當前工作的分支上。
-
合併到分支上Merge Into Branch: 你可以選擇在當前工作的分支上做過的任何修改合併到分支上。
這兩種選擇你都可以在資源控制Source Control > GitDemo菜單裏找到。注意，當你當前活躍的分支是主分支的話，第二個選擇是不可用的。
現在假設有一個開發者在我們之前創建的AnotherBranch分支上開發並在上面實現了sayHello的方法，而另一個開發者在LastBranch上開發並實現了sayByeBye的方法，而你的任務就是把這兩個新增的都添加到應用程序中下一個穩定版本。你打算怎麼做？簡單來說，當具備主分支活躍，你得先從其他兩個分支進行如下合併：
首先，確保你工作的是主分支，如果不是要先切換到主分支上。
然後，打開資源控制器Source Control > GitDemo - master > 從分支合併Merge From Branch...，然後從窗口打開並選擇AnotherBranch分支並點擊合併Merge按鈕。
一個版本比較的窗口將會出現，在那裏就會有機會再合併代碼前重新審查所有代碼修改過的地方。如果你需要，我們可以快速瀏覽一下，當你準備好了，就可以再次點擊合併Merge按鈕。
當Xcode詢問你有關該項目快照的事，點擊啓用按鈕繼續。稍等片刻，瞧！AnotherBranche分支已經合併到主分支上了。
按照同樣的方法，從LastBranch分支中合並過來。你就會發現如果你沒有提交本次版本修改過的文件，Xcode不會讓你再次合併。所以，唯一的方法只有，先提交。提交完了再嘗試從LastBranche分支上合併。在版本比較的窗口中你會發現一些紅色的區域，表示這些修改的地方會在合併之後代替藍色那部分。這意味着要合並過來的分支上的代碼將會代替當前正在工作的主分支上的相同行數的代碼，如下圖所示：
如果你使用編輯窗口下的工具欄按鈕，你可以很容易避免這種情況，並保持現有的和新增的代碼。在選擇的區域內，點擊圓形上面帶箭頭的按鈕，可以使用所 有按鈕來查看他們的效果。在下面的截圖中，我選了第一個按鈕，意味着存在在主分支上的代碼將會置於從其他分支合並過來的代碼的前面：
仔細檢查所有修改過的地方，確認任何分支裏的代碼都沒有被排除在外。一旦你完成了，你要確認所有代碼都在的，然後就點擊合併Merge按鈕。
恭喜！你已經成功從多個分支中合併代碼到一個分支上了，現在你知道如何用Xcode處理類似的事情了。
放棄修改
這個選項是對放棄那些在工程中不想被修改的文件非常有用的，因爲只需要點擊一下鼠標就可以撤銷所有自上次提交到目前所做的操作。當實現的方式不是預 期的方向，而你想從上次提交的版本重新開始工作，這時候就非常有用。注意，放棄所有改變的操作是不可恢復的選項，因此，如果你不小心做了這個操作，你將沒 有任何機會恢復到你剛剛所做的工作。所以，要謹慎。
在此前，當我們討論版本對比的時候，我們第一次看到了如何通過在編輯器窗口之間使用每個標記區域的小菜單按鈕來放棄指定代碼段的修改。這裏，我們將看到如何在整個項目中執行放棄操作，並瞬間恢復到上次提交的版本。
測試這部分的目的，打開ViewController.h文件，添加一個公共方法聲明：
1 |
@interface ViewController : UIViewController |
2 |
3 |
-(void)aVeryCoolMethod; |
4 |
5 |
@end |
現在，在ViewController.m 文件添加一小段這個方法的實現：
1 |
-(void)aVeryCoolMethod{ |
2 |
NSLog("I'm feeling that you'll discard me... Really?"); |
3 |
} |
如果你注意到了項目導航欄，M標誌旁已經添加了我們創建的兩個文件。這正是我們想要的看到的，如果取消了變化，所有修改的文件將會受影響並恢復到先前的狀態。
這裏有個很重要的細節需要提一下：你可以放棄所有文件之前所做的修改，也可以放棄部分指定文件修改。這個決定在於你，如果你想選擇性放棄，那麼請首先確保選的文件是你想放棄修改的。爲了讓後面可以看得清楚點，如果你只選擇ViewController.m文件然後打開資源控制(Source Control)菜單，你會發現在 ViewController.m會有個標題爲“放棄修改(Discard Changes)”的選項。同樣的，如果你只選擇ViewController.h文件並打開相同的菜單，你也會在ViewController.h中發 現放棄修改(Discard Changes)的選項。不過，如果你想同時放棄這兩個文件的修改（並假設這裏面會有超過兩處的修改），只需在項目瀏覽器(Project Navigator)選擇他們並再次打開資源控制器(Source Control)菜單。相應的指令變成放棄這兩個文件的修改……如下圖所示：
在這個例子中，我們不打算使用這個選項，用放棄所有改變(Discard All Changes)來代替。通過點擊它，屏幕上就會出現確認的提示窗口，這是Xcode防止你誤操作的方式。
點擊放棄所有改變(Discard All Changes...)提示框的按鈕，公共方法就會恢復到原來的樣子。正如你所見，放棄所有改變僅僅是點擊幾下就會遠離你現在的狀態，所以我再次提醒你，當你想放棄之前操作的時候要非常小心，尤其是你通常都使用資源控制器(Source Control)菜單。
總結
在本次教程中，我努力深入細緻地把如何使用Xcode管理版本和資源控制講述給大家。在幕後，真正工作的其實是git，一個非常流行和非常有用的版本控制系統。你或許發現文中並沒有提及到GitHub或 者任何有關Xcode功能的地方，但是我這麼做的目的，是想完全關注在通過Xcode進行的git管理上，除此之外，如果你知道如何處理版本控制，你也可 以直接使用GitHub。進一步說，正如我在教程開始時候經常提到的，如果你是團隊中的一員，那麼用版本控制系統來工作是強制性的。如果你是個人工作而且
你之前沒用這個的話，那麼也強烈地建議、鼓勵你現在開始使用Xcode的版本控制。這是一種保證你不會對現成的工作造成任何的損害，也不會增加工作量的方 式，除此之外，當添加新的功能來拓展你的應用程序時也變得非常容易。最後，我希望前面所展示的例子是有幫助的，以及使用Xcode來管理版本是能夠有效地 節省工作時間的。
和往常一樣，你可以隨時留下評論來分享你的看法。
（轉載自http://www.open-open.com/lib/view/open1399179356984.html）