圖比較是 GitHub Desktop 的核心功能. 它驅動你分支的交互，顯示你的改動對根分支的影響。

很多復雜的應用程序用戶界面都做得很易用。以動畫的方式解釋提交，同步，合并的效果。

為 OS X 和 Windows 提供獨立的代碼庫和設計，我們知道共享代碼是不可或缺的。像圖像這樣復雜的處理，實現兩次將是一個很大的負擔。

跨平臺代碼對我們來說不是全新的：舉例來說，代碼基于git & libgit2。共享用戶界面尊重了每個平臺的不同方式。

幸運地是，在 Electron 應用中作為一個可重用的 web 組件，比對圖已經被原型化。我們知道我們可以在 OS X 主機上實現一個本地的 web 視圖，并且在 Windows 上也提供了支持。

這里，我們會這樣做。

共享性實現

所有的 GitHub 桌面實現，作為 submodule，都是參考圖像比較。這為圖像比較和其輔助帶來了完整的 HTML/CoffeeScript/SASS 的來源，就像調試和建立腳本。

這些中的大多數對于運行應用時不太必要的，因此要建立腳本，把來源編譯成應用中嵌入的可分配的 HTML/JavaScript/CSS 文件。

在 OS X 系統中，我們用蘋果的 WebView 在 UI 中區整合圖像比較。在 Windows 系統中中，我們發現在 .NET WebBrowser 控制中的初始探索是不可運行的，所以我們在其中嵌入 CefSharp 并使用它的ChromiumWebBrowser（Chromium 網絡瀏覽器）。當這些令我們的文件大小增加時，WebView 和衍生自 Webkit 內核的 ChromiumWebBrowser 能簡化開發和調試圖像比較的變更。一般情況下，在 OS X 系統下進行圖像比較的開發者不必擔心這些應用能否在 Windows 下運行，反之亦然。

共享接口

我們必須考慮到在全平臺上的圖像比較 API，然而，重要的更改必須被整合在應用的各處。重要更改是前期討論的結果，這是一個問題，一是表現在拉取式請求中的調出，二是確保熟悉對其他已經具有機會進行評論的平臺。

我們有意識地把圖像比較 API 控制得狹窄和專一。其綜合流程如下：

1. 提取流動的和作為基礎的分支。

2. 應用請求圖像比較描繪出比較。

3. 圖像比較請求它的分支代表（其應用）來在每一分支中進行提交的批處理。

4. 應用通過提取提交并將它們移出圖像比較。

5. 重復步驟 3 和 4 直到圖像比較填充了視圖的寬度（或稍微超出一點填充空間），又或者是達到了分支點（分支匯聚的地方），表明應用發送了 0 條提交。

6. 如果圖像比較已經不能到達分支點，在滾動和重設左側尺寸來展現更多的圖像的情況下，重復步驟3到步驟5。

圖像比較仍會出現單分支，或者拉取式請求。這多少會帶來不同的影響，但整體流程仍與原來的很相似。

應用需要支持以下交互：

• 當新的提交出現時，無論是同步還是提交，應用都要把它們引入圖像比較。

• 當用戶的鼠標指針經過或選擇了提交圖像比較，和按下了按鈕，圖像比較會通知其交互代表（應用）。

• 按鈕的動作執行通常應該是異步的，以便于圖像比較能夠提示那個應用正在運行中。應用能夠命令圖像比較提示什么信息，和什么時候停止提示。

• 應用能夠改變按鈕的功能，比如，當分支已經遠程發布時，把“發布”按鈕變成“同步”按鈕。

自從所有的應用必須執行自身的流程，它們也共享周圍粗略的架構，這包括了以下：

1. 當有命令存在時（比如，用戶作出了提交命令），計算代表圖像狀態的值。

2. 分離連續狀態。

3. 通過詢問圖像比較來執行一些動作，解釋其不同之處。例如，如果兩個狀態屬于了不同的分支，應用會詢問圖像比較去描繪新的比較（或者分支，又或者是拉取式請求。如果他們是屬于同一個分支，但隨著提交命令而變化，應用就不會去詢問圖像比較，而是去遞增地插入新的提交。

非共享的實現

雖然整體流程和架構是共享的，但其實現往往是不一樣的。比如，雖然所有平臺都是用 WebKit 瀏覽器核心，但各自的橋接 API 是很不一樣的。

在 OS X 平臺上，JavaScript 核心的 API 允許我在 Object-C，Swift 和 JavaScript 之間傳遞任意的對象，函數和數組。本地代碼可以在 JavaScript 對象中調用方法，而 JavaScript 代碼也可以在本地對象中調用方法，不需要任何特殊的控制手段。我們也可以定義協議去指定對象的某個屬性來被橋接。

CefSharp，在另一方面，沒有橋接函數的數組。JavaScript 對象能夠調用本地對象的方法，但不能調用本地對象的屬性。本地對象不能調用 JavaScript 對象的方法；作為替代，你可以訪問 ChromeWebBrowser 去評估 JavaScript 來源的字符串。因為圖像比較擁有巨大的異步性，需要回收和數組，這導致在構建時，一系列 JavaScript 的墊片會進入圖像比較。

在加載中，shims 是比較圖片應用的代表。當比較圖形的要求提交時，它會通過一個回調將提交的文件回傳。Shims 將回傳值存入一個專用表格中獲得一個密鑰，調用應用并將密鑰傳遞。當應用程序獲得了請求后，它會調用回傳值，并傳遞密鑰和一組請求數組。

shims.getCommitsBefore = function (name, sha, callback) {     callbacks[key(name, sha)] = callback;
     window.native.getCommitsBefore(name, sha); }

因為 CefSharp 不能傳遞，這需要將程序模型序列化，提交請求到 JSON 的比較圖。與 OS X 的進程相比（請求的數組可以被直接傳遞），它稍稍顯得不方便，但它有一個優勢：比較圖和應用程序相互隔絕，不受期望狀態的改變而影響。

Browser.RunJsAsync("shims.didGetCommitsBefore("     + ToJson(name) + ", "     + ToJson(sha) + ", " 
    + ToJson(commits)     + ")");

最后，應用調用到 shims，傳遞 commits 的序列號數組，shims 把 commits 提交到比較圖。

shims.didGetCommitsBefore = function (name, sha, commits) {     callbacks[key(name, sha)](commits);     delete callbacks[key(name, sha)]; }

我們同時使用 CSS shims 來調整比較圖的外觀來適應主機平臺的外觀和感覺。例如，在 Windows 上，按鈕需要一個平面外觀，但是在 OS X 上，需要有輕微的梯度。同樣，Windows 的文本是 Segoe UI，OS X 的文本是 Helvetica Neue。這可以幫助我們確保在不同平臺之間的共享效應不會是一個最小公分母體驗。

前瞻

除了對照圖，教程，和許多共享的體系結構，大多數的實現在兩個平臺上仍然是不同的。也許我們所做的覆蓋 Mac 版本 GitHub 和 Windows 版本 GitHub 的桌面程序迭代相對于全部重寫是有重大好處的方式。這反過來又使我們保持在 GitHub 桌面上的更新，不至分散我們過多的注意力。

我們在這里的迭代方法，是我們開始向前迭代。有很多對照圖，讓我們有更多東西在不同的平臺間分享。向1.1致敬！