面向 Rational Team Concert 用戶的 Git 指南
如果您是 Rational Team Concert 用戶，那么您應該知道它是一個穩健、緊密集成的源代碼管理系統。但這并不意味著它適合每個軟件開發項目或團隊。我們為像我們一樣想要了解 Git 或將在新項目中使用 Git 的 Rational Team Concert 用戶編寫了本文。我們對比 Git 與 Rational Team Concert 的基本和高級特性，所以您可以看到它們有哪些共性和區別。我們還將了解如何將一些常見 Git 流轉換為 Rational Team Concert 中類似的源代碼管理模式。最后，我們會指出在從 Rational Team Concert 遷移到 Git 時應該避免的一些陷阱。
基本特性和支持
Rational Team Concert 和 Git 都對源代碼管理提供了基本和高級支持，但每個系統在源代碼控制的處理上稍有不同。例如，盡管 Git 和 Rational Team Concert 都支持 分布式開發 （意味著開發人員不需要在同一地點協作），但 Rational Team Concert 用戶可以連接到中央服務器來共享更改和協作，而 Git 用戶主要在本地克隆版本上執行操作。
代碼存儲是另一個基本特性，支持團隊協作和版本控制。在 Rational Team Concert 中，用戶創建一個個人服務器端存儲庫工作區作為其本地沙箱的鏡像，然后使用自動簽入功能將代碼推送到存儲庫工作區。無論開發人員何時在其 Eclipse IDE 中執行保存操作，都會執行簽入。
在 Git 中，用戶在其本地機器上的代碼 分支 上存儲代碼和工作。當他們準備就緒時，就會將完成的代碼推送到遠程分支。推送到遠程分支的過程比使用 Rational Team Concert 的自動簽入特性更加離散。因此，Git 用戶通常不會像 Rational Team Concert 用戶那么頻繁地推送更改。
組織代碼也是一項基本的源代碼管理功能。Rational Team Concert 使用 流 表示團隊處理的代碼。流可細分為稱為 組件 的邏輯組，可以使用流或組件來設置訪問權限。
Git 沒有提供與 Rational Team Concert 組件完全對應的實體。實際上，Git 存儲庫非常小，流會利用多個存儲庫。通常，每個存儲庫專門用于某個軟件組件或一組相關組件。
IDE 集成
Rational Team Concert 包含一個完全集成的 Eclipse IDE，支持源代碼控制管理、工作項跟蹤、項目規劃和編譯版運行，還支持用戶管理和流程管理。作為一體化解決方案，Rational Team Concert 使自定義和所有這些組件并集成到工作流中變得很容易。它還可以分別與 Rational Requirements Composer 和 Rational Quality Manager 等工具集成，以便需求收集和測試跟蹤。Rational Team Concert 的功能主要受一個富客戶端驅動，具有一個受服務器安裝支持的 Web 客戶端。一些開發人員更喜歡使用命令行客戶端來執行源代碼管理，但大部分 Rational Team Concert 用戶直接在 Eclipse IDE 中工作。
就其本身而言，Git 不包含源代碼管理以外的功能。核心 Git 二進制文件很小，目的是讓開發人員從命令行接口高效地管理源代碼。對于更喜歡它們的開發人員，Git 具有圖形擴展功能，比如 EGit 和 TortoiseGit。需要存儲庫前端來執行項目管理的開發人員，可以選擇基于 Git 的解決方案，比如 GitHub 和 BitBucket，這些解決方案提供了用戶管理和問題跟蹤等功能。
比較源代碼管理架構
Rational Team Concert 和 Git 之間的一個關鍵區別是，事實上 Git 用戶在一個托管在自己機器上的代碼存儲庫中工作。這支持 Rational Team Concert 用戶所沒有的離線開發場景。本節將演示和比較每個源代碼管理系統的基本架構和組件。
圖 1 給出了 Rational Team Concert 的源代碼控制管理系統的架構。在此圖中，可以看到本地工作站上的 Eclipse 工作區，以及遠程服務器上的存儲庫工作區和流。
Rational Team Concert SCM 架構
圖 2 給出了相應的 Git 架構。在此圖中，可以看到本地工作站中的一個工作樹和本地分支，以及遠程服務器上的遠程分支。
Git SCM 架構
表 1 定義和比較了兩個源代碼管理系統的組件。
Rational Team Concert 和 Git 的架構組件
| Rational Team Concert | Git | 備注 |
|---|---|---|
| 存儲庫 | 存儲庫 | 兩個系統中的主代碼存儲被稱為存儲庫。在 Rational Team Concert 中，服務器僅保留存儲庫的完整副本。在 Git 中，每個用戶都創建整個存儲庫的一個本地克隆版本。 |
| 沙箱 | 工作樹 | 開發人員簽出的本地文件和尚未簽入 / 提交的本地更改。 |
| 流 | 分支 | 共享的代碼行在 Rational Team Concert 中稱為 流 ，在 Git 中稱為 分支 。一個簡單的工作流有且僅有一個集成流或分支。在 Git 中，此分支的默認名稱為 主分支 。 |
| 存儲庫工作區 | 特性分支（遠程） | 實質上，Rational Team Concert 存儲庫工作區是一個存儲在中央服務器上的個人分支。Git 用戶對分支的使用更為廣泛。例如，您可以創建一個分支來支持某項特性，然后在將該特性合并到一個集成分支中后刪除該分支。Git 擁有本地和遠程分支，每個本地分支都 “跟蹤” 到一個遠程分支。 |
| 不適用 | 特性分支（本地） | Git 支持的離線開發場景比 Rational Team Concert 更多。Git 用戶可通過本地提交操作將更改提交到任何分支，然后在離線工作時將更改推送到其遠程分支。 |
| 組件 | 不適用 | Rational Team Concert 支持通過組件對流中的代碼進行邏輯分離。Git 沒有與組件對應的概念。Git 用戶傾向于將其開發工作分解到多個存儲庫。 |
| 基準 / 快照 | 標簽 | 基準、快照和標簽標記一個已知的代碼級別，是以后創建分支的啟動點。舉例而言，可以創建這些工件來標記 “release 1.0”。 |
| 更改集（活動） | 暫存更改 | 一個包含一個或多個工件更改的可變集合。 |
| 更改集（完成） | 提交 | 一個包含一個或多個更改的不可變集合。 |
比較命令和概念
Rational Team Concert 和 Git 的命令集非常相似。關鍵區別在于，Rational Team Concert 中的源代碼管理采用集中管理方法，而在 Git 中，管理工作被分散到服務器存儲庫和本地克隆版本中。
在圖 3 中，Rational Team Concert 用戶通過簽入將代碼從其 Eclipse 工作區轉移到存儲庫工作區，然后使用交付操作將代碼從存儲庫工作區轉移到遠程流。接受操作將更改同時轉移到存儲工作區和 Eclipse 工作區。
Rational Team Concert 中的命令流
圖 4 展示了將代碼轉移到一個共享的團隊分支所需執行的多個步驟。在此場景中，開發人員將更改從其工作樹添加到暫存區域，將更改提交到本地分支，將更改推送到遠程分支，最后合并到團隊分支。拉入操作將更改從一個分支一直轉移到一個工作樹。
Git 中的一個命令流
表 2 定義并比較了 Rational Team Concert 和 Git 中的關鍵命令。
Rational Team Concert 和 Git 中的關鍵命令
| Rational Team Concert | Git | 備注 |
|---|---|---|
| 簽入 | 添加 | 在本地工作副本中準備將要在上游集成的更改。在 Rational Team Concert 中，此操作將更改發送到服務器進行安全保護。在 Git 中，它將更改發送到本地暫存區域。 |
| 交付 | 推送 / 合并 | Rational Team Concert 用戶將來自其存儲庫工作區的代碼集成到一個流中。如果需要一次合并，則會阻止交付。Git 用戶通常首先通過推送操作將代碼交付到遠程分支（稱為 特性分支 ）。在一個不同操作中，它們將此分支合并到一個主要集成分支（也稱為 主分支 ）。如果合并將需要手動干預，Git 會阻止合并，直到用戶解決任何沖突。 |
| 注釋 / 顯示歷史 | 日志 | 兩個系統都提供了所有文件或所有提交內的更改的完整可跟蹤性。 |
| 加載 | 克隆 | 從主存儲庫將源代碼下載到本地工作站。Rational Team Concert 提供了部分加載存儲庫的能力。 |
| 接受 | 拉入 | 從主存儲庫上的活動分支將更改下載到本地工作區域。Rational Team Concert 的接受操作從用戶連接到的流拉入所有更改。Git 的拉入操作與接受操作直接對應，它將更改從一個分支拉到另一個分支中（例如從遠程分支拉到本地分支）。 |
| 不適用 | 抓取 | 從用戶跟蹤的所有遠程分支將更改下載到其本地存儲庫克隆版本。用戶從該分支執行拉入操作之前，抓取 不會 將用戶的任何本地分支升級到該遠程分支的狀態。 |
| 鎖定 / 解鎖 | 不適用 | 鎖定會阻止其他用戶修改文件。Git 沒有這種機制。 |
| 放棄（活動更改集） | 取消暫存 | 在 Rational Team Concert 中，此命令從存儲庫工作區和本地沙箱刪除更改。在 Git 中，它僅從本地分支刪除更改，保持工作樹原封不動。 |
| 放棄（已完成更改集） | 重置 | 更新本地狀態，就像給定更改從未下載一樣。在 Rational Team Concert 中，如果向狀態中引入了空白，將阻止放棄操作。Git 為其重置操作提供了多個選項。 reset—hard 大體相當于 Rational Team Concert 放棄操作。 |
| 狀態（未決更改） | 狀態 | 兩個工具都允許您通過多種方式對本地狀態與遠程狀態進行比較。 |
| 更改您的流目標 | 簽出 | 切換到不同的開發線，例如在一個維護分支上工作而不是進行主線開發。 |
| 創建快照 | 創建標簽 | 使用已知標識符標記存儲庫的狀態（例如 “Release 1.0”） |
| 創建存儲庫工作區 / 流 | 創建分支 | 創建一個新開發線 / 集成點。 |
| 暫停 | 存放 | 將存儲庫工作區和工作樹恢復到執行暫停的更改之前的狀態。在 Rational Team Concert 中，暫停的更改集存儲在服務器上，可歸入同一個用戶擁有的一個不同的存儲庫工作區。在 Git 中，存放完全在本地執行。 |
| 恢復 | Git stash apply | 暫停 / 存放 的相反操作；此命令將暫停或存放的更改應用于用戶的工作區域。 |
| 反轉 | 復原 | 創建一個與相關更改 “相反” 的更改集。有效地撤銷相關更改。 |
理解 Git 場景
Rational Team Concert 和 Git 中的使用模式代表著兩種根本不同的源代碼管理哲學和方法。盡管開發人員傾向于在每個開發場景中以相同方式使用 Rational Team Concert（得益于它的可預測性和均勻性），Git 用戶遵循且適應各種各樣的使用模式。遷移到 Git 的一個重要方面是，確定哪些模式（或 Git 用語中的 流 ）適合您的項目需求。
GitHub Flow 和 Git Flow 是兩種最常用的 Git 模式，所以這里將看看每種模式的特征。考慮如何實現 Rational Team Concert 中的模式才有助于您在使用 Git 時采用它們。
GitHub Flow
GitHub Flow 是一個使用相對短期分支為基礎的源代碼控制模式，其中每個分支表示一個特定的開發或其他某個小工作單元。當該工作單元完成且所有測試都通過時，分支所有者將該分支合并到主分支，然后刪除與該工作單元關聯的分支。
如果想要在 Rational Team Concert 中實現此模式，需要先根據集成流創建一個新 “特性” 流，然后將一個或多個存儲庫工作流傳輸到它，直到開發完成。然后可以將這些存儲庫工作區中的一個傳輸到集成流，并一次交付所有更改。（回想一下，Rational Team Concert 不允許直接的流間交付。）在 Rational Team Concert 和 Git 中，如果一次合并沖突會阻止代碼集成，您會收到警告。在這種情況下，系統會提示您解決合并問題。
Git Flow
Git Flow 基于 Vincent Driessen 開發的 “ 一個成功的分支模型 ”。像 GitHub Flow 一樣，它使用從一個共享開發分支分叉出來的短期特性分支。主要區別是它對發布候選版使用了不同的分支，而且不會頻繁地交付到主分支。
要與 Git Flow 建立大體對應關系，在 Rational Team Concert 中，您可以使用 “ 如何保持在 Rational Team Concert 中順利傳輸流 ” 中列出的技術。在本例中，您的團隊將為每日開發設置一個要合并形成的集成流，就像在 GitHub Flow 中所做的那樣。然后，您可以使用一個 “發布候選版” 構建流程將集成流升級到發布候選流。接受發布候選版后，您的團隊可以設置一個類似的編譯版來將發布候選流升級到主流，最好使用快照標簽，比如 Release 1.0。
因為 Rational Team Concert 允許您從任何給定快照快速創建流，所以您可以在 Rational Team Concert 中實現此模式的輕量型版本。您只需要小心地管理 Git 通常用來創建新分支的流位置上的流快照。
從 Rational Team Concert 遷移到 Git
切換到新開發工具通常需要進行一些調整。我們發現，以下流程更改支持更順利地從 Rational Team Concert 遷移到 Git：
- 使用短期分支 。Git 流最適合包含較小工作批次的短期特性分支。Rational Team Concert 中的流可能是長期的，開發人員通常會交付較大的批次。短期、專注的流支持通過拉入請求更輕松地審核代碼，而且更容易供其他開發人員合并。保持您的 Git 分支關注點緊湊，而不是一次交付太多代碼。
- 經常提交 。在 Rational Team Concert 中，交付的更改被分發給每個人。開發人員傾向于更長時間保留代碼，以確保它在交付之前完全就緒。Git 的理念是鼓勵頻繁的分支，即使是簡單的特性。Git 一般提交到個人分支，所以在您與主分支合并之前，您的代碼不會影響其他任何用戶。通過經常提交，您會留下所完成工作的詳細的可審計線索。這有助于更好地完成代碼審核，因為您對已更新的內容進行了說明。團隊成員也能查看所有遠程分支，這使他們能夠輕松查看每個團隊成員的工作內容，實現更有效的全團隊協同配合。
- 使用多個分支 。不要害怕一次打開多個分支。在 Rational Team Concert 中，可以將一個工作區域（沙箱）關聯到一個存儲庫工作區，而 Git 允許輕松地將沙箱關聯到任意多個分支。這有助于保持您的分支小而專注。通過采用多個分支，一次處理多個代碼區域。當您交付時，您的代碼審核工作將通過每個特定任務的分支限制到該任務。
結束語
本文是為那些習慣使用 Rational Team Concert 且想要進一步了解 Git 的開發人員而編寫的。若想成功地將您的工作流從 Rational Team Concert 調整為 Git，需要以不同方式思考如何管理和分發代碼。我們的目標是幫助您理解兩個源代碼控制系統之間的原理、架構和命令結構差異。
來自：http://www.ibm.com/developerworks/cn/devops/d-guide-git-rational-team-concert-trs/index.html?ca=drs-