開発が始まったばかりではあるが，GoogleがGit Ketchの最初のコミットを発表した。レジリエンスとスケーラビリティを目的として複数のGitサーバに情報を複製する，マルチマスタのGit管理システムである。JavaベースのGitサーバであるJGitをベースとして変更を加えているが，それ以外のGitサーバでもマルチマスタのクラスタに参加することができる。
Gitは分散型のソース管理リポジトリシステムとして設計されているが，ほとんどの組織は集中型のアプローチを採用している。すなわち，コードの“ゴールデンコピー”を持ったマスタリポジトリがあって，すべての開発者が変更のプッシュとアップデートのプルを行なう，という運用方法である。開発者の間で変更を直接適用することも可能だが，このような運用が行なわれるのはまれだ。こうした集中型アプローチは，単一障害点を発生させることになる。
JGitはこの問題に対して，DFS(Distributed File System)ストレージオプションという形で，部分的な解決策を提供している。部分的というのは，JGitが提供しているのが，DFSストレージのコントラクトを定義する抽象クラスセット定義のみだからだ。データのレプリケーションをサポートするアーキテクチャの設計や抽象クラスの実装は，ユーザが行なわなくてはならない。これはつまり，JGit DFSの実装に相応のリソースを投資しなければならないという意味であり，企業にとっては導入を躊躇する理由になる(Googleは既知の実装を所持している数少ない企業のひとつだ)。
Ketchは違う戦略を採用する。DFSでデータを複製可能な単一のGitサーバを定義する代わりに，Ketchでは複数の一般的なGitサーバの存在を前提にする。これらのサーバは互いに同期可能であり，それゆえに“マルチマスタ”なのだ。任意の時点において，サーバのひとつがリーダとして機能し，それ以外はスレーブになる。いずれかのサーバにプッシュ要求が送信されると，その要求はリーダに転送される。リーダはそのプッシュ要求をすべてのサーバに送信する。サーバの大部分がプッシュ要求の処理に成功した場合にのみ，最初の発信者に操作の成功が通知される仕組みだ。Raftアルゴリズムを基本とするこの機構により，少なくともサーバの大半に要求された変更が反映されていることが保証される。データ操作に失敗したサーバは，その他のものと同期を行なえばよい。現時点でリーダになれるのはJGitサーバのみだが，アトミックなプッシュを実装したGitサーバであれば，マルチマスタクラスタの参加サーバとして機能することができる。
提案中の変更はJGitのGerritで，ツールや進捗状況に関する詳細はJGitのeメール配布リストで，それぞれ入手が可能だ。