ギット

ギット

リポジトリの作成、ファイルの追加、リモート同期を示すコマンドラインセッション
原作者	リーナス・トーバルズ[1]
開発者	浜野純男他[2]
初回リリース	2005年4月7日; 19年前 ( 2005-04-07 )
安定リリース	2.46.2 [3]  / 2024年9月23日
リポジトリ	git.kernel.org/pub/scm/git/git.git
書かれた	主にC言語で書かれ、GUIとプログラミングスクリプトはシェルスクリプト、Perl、Tcl、Pythonで書かれている[4] [5]
オペレーティング·システム	POSIX ( Linux、macOS、Solaris、AIX )、Windows
利用可能	英語
タイプ	バージョン管理
ライセンス	GPL-2.0のみ[i] [7]
Webサイト	git-scm.com

Git（/ ɡɪt /）^[8]は、ファイルのバージョンを追跡する分散バージョン管理 システム^[9]です。ソフトウェアを共同で開発しているプログラマーがソースコードを管理するのによく使用されます。

Gitの設計目標には、速度、データの整合性、分散型非線形ワークフロー（異なるコンピュータ上で実行される数千の並列ブランチ）のサポートが含まれています。^{[10] [11] [12]}

Gitは、 Linuxカーネルの開発に携わるLinus Torvalds氏らによって開発されました。^[13]

他のほとんどの分散バージョン管理システムと同様に、またほとんどのクライアントサーバーシステムとは異なり、Gitは、ネットワークアクセスや中央サーバーから独立して、履歴とバージョン追跡機能を備えたリポジトリ全体のローカルコピー（別名レポ）を維持します。レポは、バージョン管理機能を提供するために追加の隠しファイルとともに各コンピューターの標準ディレクトリに保存されます。 ^[14] Gitは、履歴を共有するリポジトリ（互いにコピー（クローン）された）間で変更を同期する機能を提供します。コラボレーションのために、Gitはリモートマシン上のレポとの同期をサポートしています。すべてのレポ（同じ履歴を持つ）はピアですが、開発者は多くの場合、統合されたコピーを保持するレポをホストするために中央サーバーを使用します。

Git は、GPL-2.0 のみのライセンスの下で共有される無料のオープンソース ソフトウェアです。

「Git」という商標はSoftware Freedom Conservancyによって登録されており、オープンソースコミュニティにおける公式な認知と継続的な進化を示しています。

現在、Gitは事実上の標準バージョン管理システムです。最も人気のある分散型バージョン管理システムであり、2022年現在、開発者の約95％が主要なバージョン管理システムとしてGitを使用しています。 ^{[15]プロの開発者の間で最も広く使用されているソースコード管理ツールです。Gitリポジトリサービスには、} GitHub、SourceForge、Bitbucket、GitLabなどがあります。^{[16] [17] [18] [19] [20]}

トーバルズは、2002年以来Linuxカーネル開発に使用されてきた独自のソースコード管理（SCM）システムであるBitKeeperのフリーライセンスがLinuxで取り消された後、2005年4月にGitの開発を開始しました。 ^{[21] [22]} BitKeeperの著作権者であるラリー・マクボイは、アンドリュー・トリジェルがBitKeeperプロトコルをリバースエンジニアリングしてSourcePullerを作成したと主張しました。^[23]同じ事件は、別のバージョン管理システムである Mercurialの作成にも拍車をかけました。

トーバルズは BitKeeper のような分散システムを望んでいたが、利用可能なフリーシステムはどれも彼のニーズを満たしていなかった。彼は、パッチを適用して関連するメタデータをすべて更新するのに 30 秒かかるソース コントロール管理システムの例を挙げ、これでは Linux カーネル開発のニーズには対応できないと指摘した。Linux カーネル開発では、他のメンテナーとの同期に 250 ものアクションが必要になる可能性がある。彼は設計基準として、パッチ適用に 3 秒以上かかるべきではないと指定し、さらに 3 つの目標を追加した。^[10]

• 何をすべきでないかについての例として、 Concurrent Versions System (CVS)を挙げてみましょう。疑わしい場合は、まったく逆の決定を下してください。^[12]
• 分散型のBitKeeperのようなワークフローをサポートします。^[12]
• 偶発的または悪意のある腐敗に対する非常に強力な保護策を講じる。^[11]

これらの基準により、当時使用されていたすべてのバージョン管理システムが排除されたため、2.6.12-rc2 Linuxカーネル開発リリースの直後に、Torvaldsは独自のバージョン管理システムの作成に着手しました。^[12]

Gitの開発は2005年4月3日に始まりました。^[24]トーバルズは4月6日にプロジェクトを発表し、翌日にはセルフホスティングを開始しました。 ^{[24] [25]}複数のブランチの最初のマージは4月18日に行われました。^[26]トーバルズはパフォーマンス目標を達成しました。4月29日、初期のGitは1秒あたり6.7パッチの速度でLinuxカーネルツリーにパッチを記録してベンチマークされました。^[27] 6月16日、Gitはカーネル2.6.12のリリースを管理しました。^[28]

2005年7月26日、トルバルズはプロジェクトの主要貢献者であるジュニオ・ハマノにメンテナンスを引き継いだ。 ^[29]ハマノは2005年12月21日の1.0リリースを担当した。^[30]

トルバルズは、 git （イギリス英語の俗語で「不愉快な人」を意味する）という名前について皮肉を込めてこう言った。「私は自己中心的な野郎で、自分のプロジェクトにはすべて自分の名前を付けている。最初は「Linux」、今は「git」だ。」^{[31] [32]} manページでは、 Gitを「愚かなコンテンツトラッカー」と表現している。^[33]

ソースコードのread-meファイルにはさらに詳しい説明がある: ^[34]

「git」は気分に応じて何にでも意味を持ちます。

• 発音可能なランダムな 3 文字の組み合わせですが、一般的な UNIX コマンドでは実際には使用されません。これが「get」の誤った発音であるという事実は、関係があるかどうかわかりません。
• 愚か。軽蔑すべき、卑劣。単純。スラング辞典から選んでください。
• 「グローバル情報トラッカー」：あなたは気分が良く、実際にそれがうまく機能しています。天使が歌い、突然光が部屋を満たします。
• 「クソバカなトラック一杯のクソ」：壊れたとき。

Git のソース コードでは、このプログラムを「地獄の情報マネージャー」と呼んでいます。

Gitの設計は、大規模な分散開発プロジェクトを維持してきたTorvaldsのLinuxでの経験と、同じプロジェクトで得たファイルシステムのパフォーマンスに関する深い知識、そして短期間で動作するシステムを作成するという緊急の必要性を統合したものです。これらの影響により、次のような実装の選択が生まれました。^[13]

非線形開発を強力にサポート

Git は迅速なブランチ作成とマージをサポートし、非線形の開発履歴を視覚化してナビゲートするための特別なツールが含まれています。Git では、変更はさまざまなレビュー担当者に渡されるため、書き込まれるよりも頻繁にマージされるという前提が基本となっています。Git では、ブランチは非常に軽量です。ブランチは 1 つのコミットへの参照にすぎません。

分散開発

Darcs、BitKeeper、Mercurial、Bazaar、Monotoneと同様に、Gitは各開発者に完全な開発履歴のローカルコピーを提供し、変更はそのようなリポジトリ間でコピーされます。これらの変更は追加された開発ブランチとしてインポートされ、ローカルで開発されたブランチと同じ方法でマージできます。^[35]

既存のシステムやプロトコルとの互換性

リポジトリは、Hypertext Transfer Protocol Secure (HTTPS)、Hypertext Transfer Protocol (HTTP)、File Transfer Protocol (FTP)、またはプレーンソケットまたはSecure Shell (ssh) 経由のGitプロトコルを介して公開できます。GitにはCVSサーバーエミュレーションもあり、既存のCVSクライアントやIDEプラグインを使用してGitリポジトリにアクセスできます。Subversionリポジトリはgit-svnで直接使用できます。^[36]

大規模プロジェクトの効率的な処理

トーバルズはGitを非常に高速でスケーラブルであると評しており^[37]、Mozillaによるパフォーマンステスト^{[38]では、大}規模なリポジトリの差分処理がMercurialやGNU Bazaarよりも桁違いに高速であることが示されました。また、ローカルに保存されたリポジトリからバージョン履歴を取得するのは、リモートサーバーから取得するよりも100倍高速です^{[39] 。}

履歴の暗号認証

Gitの履歴は、特定のバージョンのID（ Git用語ではコミット）がそのコミットに至るまでの完全な開発履歴に依存するような方法で保存されます。一度公開されると、気づかれずに古いバージョンを変更することはできません。構造はMerkleツリーに似ていますが、ノードとリーフにデータが追加されています。^[40]（MercurialとMonotoneにもこの特性があります。）

ツールキットベースの設計

GitはC言語で書かれたプログラムとそれらのプログラムをラップするシェルスクリプトのセットとして設計されました。 ^[41]これらのスクリプトのほとんどはその後、速度と移植性のためにC言語で書き直されましたが、設計はそのまま残っており、コンポーネントを連結するのは簡単です。^[42]

プラグ可能なマージ戦略

ツールキット設計の一環として、Gitは不完全なマージのモデルを明確に定義しており、それを完了するための複数のアルゴリズムを備えており、最終的にはマージを自動的に完了することができず、手動編集が必要であることをユーザーに通知します。^[43]

ゴミは回収されるまで蓄積される

操作を中止したり変更を取り消したりすると、データベースに役に立たない未処理オブジェクトが残ります。これらは通常、継続的に増え続ける必要なオブジェクトの履歴のごく一部です。リポジトリに十分な数の未処理オブジェクトが作成されると、Git は自動的にガベージコレクションを実行します。ガベージコレクションは、を使用して明示的に呼び出すことができますgit gc。^{[44] [45]}

定期的な明示的なオブジェクトパッキング

Git は、新しく作成された各オブジェクトを個別のファイルとして保存します。個別に圧縮されているとはいえ、これは大量のスペースを占有し、非効率的です。この問題は、多数のオブジェクトを差分圧縮して1 つのファイル (またはネットワーク バイト ストリーム) に格納するパックを使用することで解決されます。このパックは、パックファイルと呼ばれます。パックは、同じ名前のファイルはおそらく類似しているというヒューリスティックを使用して圧縮されますが、正確性についてはこれに依存しません。各パックファイルに対応するインデックス ファイルが作成され、パックファイル内の各オブジェクトのオフセットが示されます。新しく作成されたオブジェクト (新しく追加された履歴を含む) は、依然として単一のオブジェクトとして保存されるため、スペース効率を維持するには定期的な再パックが必要です。リポジトリをパックするプロセスは、非常に計算コストがかかる場合があります。オブジェクトがリポジトリ内に緩いが迅速に生成される形式で存在できるようにすることで、Git は、時間の節約になるとき (たとえば、1 日の終わり) までコストのかかるパック操作を延期できるようにします。Git は定期的に自動的に再パックしますが、コマンドを使用して手動で再パックすることもできます。^[46]データの整合性のために、パックファイルとそのインデックスの両方にSHA-1チェックサム^[47]が含まれており、パックファイルのファイル名にもSHA-1チェックサムが含まれています。リポジトリの整合性をチェックするには、コマンドを実行します。^{[48] [49]}git gcgit fsck

Git のもう 1 つの特性は、ファイルのディレクトリ ツリーのスナップショットを作成することです。ソース コードのバージョンを追跡する最も初期のシステムであるソース コード コントロール システム(SCCS) とリビジョン コントロール システム(RCS) は、個々のファイルに対して動作し、インターリーブされたデルタ(SCCS) またはデルタ エンコーディング(RCS) (ほとんどが類似した) バージョンから得られるスペースの節約を重視していました。その後のリビジョン コントロール システムでは、プロジェクトの複数のリビジョンにわたってファイルが ID を持つという概念が維持されました。しかし、Torvalds はこの概念を拒否しました。^[50]その結果、Git はソース コード ツリーの下のどのレベルでもファイル リビジョンの関係を明示的に記録しません。

これらの暗黙的なリビジョン関係には、いくつかの重要な結果が伴います。

• 1 つのファイルの変更履歴を調べるのは、プロジェクト全体を調べるよりも少しコストがかかります。^[51]特定のファイルに影響する変更履歴を取得するには、Git はグローバル履歴を調べ、各変更がそのファイルを変更したかどうかを判断する必要があります。ただし、この履歴調査方法を使用すると、Git は任意のファイル セットの変更を示す単一の履歴を同等の効率で生成できます。たとえば、ソース ツリーのサブディレクトリと関連するグローバル ヘッダー ファイルは非常に一般的なケースです。
• 名前の変更は、明示的ではなく暗黙的に処理されます。CVS に対する一般的な苦情は、 CVSがファイル名を使用してリビジョン履歴を識別するため、ファイルの移動や名前の変更を行うと、履歴が中断されるか、履歴の名前が変更されて履歴が不正確になるというものです。CVS 以降のリビジョン管理システムのほとんどは、名前を変更しても存続する一意で長期間有効な名前 ( inode番号に類似) をファイルに与えることでこの問題を解決しています。Git はそのような識別子を記録しないため、これは利点であるとされています。^{[52] [53]} ソースコードファイルは分割または結合される場合があり、単に名前が変更されることもあります。 ^[54]これを単純な名前変更として記録すると、(不変の) 履歴に何が起こったかの不正確な説明が固定されます。Git は、スナップショットの作成時に名前の変更を記録するのではなく、スナップショットの履歴を参照するときに名前の変更を検出することでこの問題に対処しています。^{[55] （簡単に言うと、リビジョン}Nのファイルがある場合、リビジョンN − 1 の同じ名前のファイルがそのデフォルトの祖先になります。ただし、リビジョンN −  1 に同じ名前のファイルがない場合、Git はリビジョンN  − 1 にのみ存在し、新しいファイルに非常に類似した ファイルを検索します。）ただし、履歴を確認するたびにCPU を集中的に使用する作業が必要になり、ヒューリスティックを調整するためのオプションがいくつかあります。このメカニズムは常に機能するとは限りません。同じコミットで変更を加えて名前が変更されたファイルは、古いファイルの削除と新しいファイルの作成として読み取られることがあります。開発者は、名前の変更と変更を別々にコミットすることで、この制限を回避できます。

Gitはいくつかのマージ戦略を実装しており、マージ時にデフォルト以外の戦略を選択することもできます。^[56]

• 解決: 従来の3 方向マージアルゴリズム。
• recursive : これは、1 つのブランチをプルまたはマージする場合のデフォルトであり、3 方向マージ アルゴリズムのバリエーションです。

  3 方向マージに使用できる共通の祖先が複数ある場合、共通の祖先のマージされたツリーを作成し、それを 3 方向マージの参照ツリーとして使用します。これにより、Linux 2.6 カーネル開発履歴から取得した以前のマージ コミットで行われたテストによって、誤ったマージを引き起こすことなくマージの競合が少なくなることが報告されています。また、名前の変更を伴うマージを検出して処理することもできます。

  — リーナス・トーバルズ^[57]

• octopus : 2 つ以上のヘッドをマージする場合のデフォルトです。

Gitのプリミティブは本質的にはソースコード管理システムではない。Torvaldsは次のように説明している。^[58]

多くの点で、git は単なるファイルシステムとして見ることができます。つまり、コンテンツ アドレス可能であり、バージョン管理の概念がありますが、私は実際にはファイルシステム担当者の観点から問題に取り組んで git を設計しました (そう、私はカーネルを専門としています)。実際、従来の SCM システムを作成することにはまったく興味がありません。

この初期の設計アプローチから、Gitは従来のSCMに期待される機能の完全なセットを開発しました。^[59]ほとんどの機能は必要に応じて作成され、時間の経過とともに改良および拡張されました。

Git には、作業ディレクトリとコミットされる次のリビジョンに関する情報をキャッシュする可変インデックス(ステージまたはキャッシュとも呼ばれます) と、不変オブジェクトを格納する オブジェクト データベースという 2 つのデータ構造があります。

インデックスは、オブジェクト データベースと作業ツリー間の接続ポイントとして機能します。

オブジェクトストアには5種類のオブジェクトが含まれています: ^{[60] [48]}

• BLOBはファイルの内容です。BLOBには適切なファイル名、タイムスタンプ、その他のメタデータはありません（BLOBの名前は内部的にはその内容のハッシュです）。Gitでは、各BLOBはファイルのバージョンであり、その中にファイルのデータがあります。^[61]
• ツリーオブジェクトはディレクトリに相当します。ツリーオブジェクトにはファイル名のリスト^[62]が含まれており、各ファイル名にはいくつかの型ビットと、そのファイル、シンボリックリンク、またはディレクトリの内容であるブロブまたはツリーオブジェクトへの参照が含まれています。これらのオブジェクトはソースツリーのスナップショットです。(全体として、これはMerkleツリーを構成します。つまり、ルートツリーのハッシュが1つだけで十分であり、コミットで実際に使用され、任意の数のサブディレクトリとファイルのツリー構造全体の正確な状態を正確に特定します。)
• コミットオブジェクトはツリーオブジェクトを履歴にリンクします。コミットオブジェクトには、ツリーオブジェクトの名前（最上位のソースディレクトリ）、タイムスタンプ、ログメッセージ、および0個以上の親コミットオブジェクトの名前が含まれます。^[63]
• タグオブジェクトは、別のオブジェクトへの参照を含むコンテナであり、別のオブジェクトに関連する追加のメタデータを保持できます。最も一般的には、Gitによって追跡されているデータの特定のリリースに対応するコミットオブジェクトのデジタル署名を保存するために使用されます。 ^[64]
• パックファイルオブジェクトは、さまざまなオブジェクトをzlib圧縮バンドルに集めて、コンパクトにし、ネットワークプロトコル経由で簡単に転送できるようにします。^[65]

各オブジェクトは、その内容の SHA-1ハッシュによって識別されます。Git はハッシュを計算し、この値をオブジェクトの名前として使用します。オブジェクトは、ハッシュの最初の 2 文字に一致するディレクトリに配置されます。ハッシュの残りの部分は、そのオブジェクトのファイル名として使用されます。

Git は、ファイルの各リビジョンを一意の BLOB として保存します。BLOB 間の関係は、ツリーとコミット オブジェクトを調べることで確認できます。新しく追加されたオブジェクトは、zlib 圧縮を使用して全体が保存されます。これにより、大量のディスク領域がすぐに消費される可能性があるため、オブジェクトをパックに結合して、デルタ圧縮を使用して領域を節約し、BLOB を他の BLOB に対する変更として保存することができます。

さらに、Gitはさまざまなコミットの場所を示すためにrefs（referencesの略）と呼ばれるラベルを保存します。これらは参照データベースに保存され、それぞれ次のようになります。^[66]

• ヘッド (ブランチ) : その上にコミットが行われると、新しいコミットに自動的に進む名前付き参照。
• HEAD : コミットを作成するために作業ツリーと比較される予約済みのヘッド。
• タグ: ブランチ参照と同様ですが、特定のコミットに固定されます。履歴の重要なポイントにラベルを付けるために使用されます。

Gitのコマンドラインインターフェースでよく使われるコマンドは以下の通り: ^{[67] [68]}

• git initgit リポジトリを作成するために使用されます。
• git clone [URL]は、外部 URL から Git リポジトリをクローン(複製) します。
• git add [file]は、git の作業ディレクトリ(コミットされるファイル)にファイルを追加します。
• git commit -m [commit message]は、現在の作業ディレクトリからファイルをコミットします(そのため、それらのファイルはリポジトリの履歴の一部になります)。

.gitignoreファイルは、Git リポジトリ内にプレーンテキストファイルとして作成することができます。.gitignoreファイルにリストされているファイルはGit によって追跡されません。^{[69] : 3–4}この機能を使用すると、キーやパスワードが設定されたファイル、さまざまな無関係なファイル、大きなファイル (GitHub がアップロードを拒否するファイル) を無視することができます。^[70]

Git データベース内の参照されていないすべてのオブジェクトは、ガベージ コレクション コマンドを使用して、または自動的にクリーンアップされる可能性があります。オブジェクトは、別のオブジェクトまたは明示的な参照によって参照される場合があります。Git にはさまざまな種類の参照があります。参照を作成、移動、および削除するコマンドは異なります。にgit show-refすべての参照がリストされています。いくつかの種類は次のとおりです。

• heads : オブジェクトをローカルに参照します。
• remotes : リモートリポジトリに存在するオブジェクトを参照します。
• stash : まだコミットされていないオブジェクトを参照します。
• meta :例: ベアリポジトリ内の設定、ユーザー権限。refs/meta/config名前空間は遡及的に導入され、Gerritによって使用される。^[71]
• タグ:上記を参照してください。

Git（C言語での主な実装）は主にLinux上で開発されていますが、BSD（DragonFly BSD、FreeBSD、NetBSD、OpenBSD）、Solaris、macOS、Windowsなど、ほとんどの主要なオペレーティングシステムもサポートしています。^{[72] [73]}

Gitの最初のWindowsポートは、主にLinuxバージョンをホストするLinuxエミュレーションフレームワークでした。WindowsにGitをインストールすると、同様の名前のProgram Filesディレクトリが作成され、GNU Compiler CollectionのMingw-w64ポート、Perl 5、MSYS2 （ Windows用のUnixライクなエミュレーション環境であるCygwinのフォーク）、およびLinuxユーティリティとライブラリのさまざまなWindowsポートまたはエミュレーションが含まれます。現在、GitのネイティブWindowsビルドは、32ビットおよび64ビットのインストーラーとして配布されています。 ^[74] gitの公式Webサイトでは現在、MSYS2環境を使用したWindows用のGitのビルドを維持しています。^[75]

GitのJGit実装は純粋なJavaソフトウェアライブラリであり、あらゆるJavaアプリケーションに組み込むことができるように設計されています。JGitは、Gerritコードレビューツールや、 Eclipse IDEのGitクライアントであるEGitで使用されています。^[76]

Go-gitは純粋なGoで書かれたGitのオープンソース実装です。^[77]現在、 GitコードリポジトリのSQLインターフェースとしてプロジェクトをバックアップし、 Gitに暗号化を提供するために使用されています。 [ ^{78 ]}

Dulwichは純粋なPythonで書かれたGitの実装であり、CPython 3.6以降とPypyをサポートしています。^[80]

Gitのlibgit2実装は、他の依存関係のないANSI Cソフトウェアライブラリであり、Windows、Linux、macOS、BSDなどの複数のプラットフォームで構築できます。^[81] Ruby、Python、Haskellなど、多くのプログラミング言語のバインディングがあります。^{[82] [83] [84]}

JS-GitはGitのサブセットのJavaScript実装です。 ^[85]

GameOfTreesはOpenBSDプロジェクトのためのGitのオープンソース実装です。^[86]

Git は分散型バージョン管理システムなので、そのままサーバーとして使用できます。Git には、git daemonGit プロトコルで実行される単純な TCP サーバーを起動する組み込みコマンドが付属しています。^{[87] [88]}専用の Git HTTP サーバーは、アクセス制御の追加、Web インターフェイス経由での Git リポジトリの内容の表示、複数のリポジトリの管理など、さまざまな機能を提供します。既存の Git リポジトリを複製して共有し、他のユーザーが集中リポジトリとして使用することもできます。また、Git ソフトウェアをインストールしてユーザーがログインできるようにするだけで、リモート シェル経由でアクセスすることもできます。^{[89] Git サーバーは通常、} TCP ポート9418でリッスンします。^[90]

• Gitバイナリを使用してGitサーバーをホストする。^[91]
• Gerrit は、コードレビューをサポートし、ssh、統合されたApache MINAまたは OpenSSH、または統合されたJetty Web サーバー経由でアクセスできるように構成可能な Git サーバーです。Gerrit は、LDAP、Active Directory、OpenID、OAuth、Kerberos/GSSAPI、X509 https クライアント証明書の統合を提供します。Gerrit 3.0 では、すべての構成が Git リポジトリとして保存され、実行にデータベースは必要ありません。Gerrit には、コアに実装されたプル リクエスト機能がありますが、そのための GUI がありません。
• PhabricatorはFacebookからスピンオフした。Facebookは主にMercurialを使用しているため、Gitのサポートはそれほど目立っていません。^[92]
• RhodeCode Community Edition (CE) は、 AGPLv3 ライセンスでGit、Mercurial、Subversion をサポートします。
• Kallithea は、Git とMercurial の両方をサポートし、 GPL ライセンスでPythonで開発されました。
• gitolite ^[93]のような外部プロジェクトは、 Gitソフトウェア上でスクリプトを提供し、きめ細かいアクセス制御を提供します。
• セルフホスティング用のFLOSSソリューションは他にもいくつかあり、Gogs、^{[94]、 Gogsのフォークである} Gitea、そしてGiteaのフォークであるForgejoなどがあります。Gogsと、前述の2つの派生製品は、Go言語を使用して開発されています。3つのソリューションはすべてMITライセンスの下で提供されています。

Gitリポジトリをサービスとして提供するサービスは数多くある。最も人気のあるものはGitHub、SourceForge、Bitbucket、GitLabである。^{[95] [17] [18] [19] [20]}

強力なバージョン管理システムである Git は、コマンドライン インターフェイスが使いにくい場合があります。Git GUI クライアントは、Git リポジトリとのやり取りを簡素化するグラフィカル ユーザー インターフェイス (GUI) を提供します。

これらの GUI は、ブランチ、コミット、ファイルの変更など、プロジェクトの履歴を視覚的に表示します。また、変更のステージング、コミットの作成、ブランチの管理などのアクションを効率化します。ビジュアル diff ツールは、同時開発から生じるマージ競合の解決に役立ちます。

GitにはTcl/Tk GUIが付属しており、ユーザーはコミットの作成と修正、ブランチの作成とマージ、リモートリポジトリとのやり取りなどのアクションを実行できます。^[96]

公式GUIに加えて、GitHub Desktop、SourceTree、TortoiseGitなど、Gitで配布される公式GUIと同様の機能を提供するサードパーティのインターフェースが多数存在します。^[97]

GUI クライアントを使用すると、Git の習得と使用が容易になり、ワークフローの効率が向上し、エラーが減少します。人気のあるオプションには、クロスプラットフォームの GitKraken Desktop (フリーミアム) と Sourcetree (無料/有料)、または Windows/macOS 用の GitHub Desktop (無料) や Windows 用の TortoiseGit (無料) などのプラットフォーム固有の選択肢があります。

Git には組み込みの GUI ツール (git-gui、gitk) が用意されていますが、プラットフォーム固有のユーザー設定に対応するサードパーティのオプションも幅広く用意されています。

• GitHub デスクトップ
• ソースツリー
• トータスGit
• Git 拡張機能
• ギット
• MeGit (EGit ベース)
• GitUI

• GitHub デスクトップ
• ソースツリー

• ギット
• MeGit (EGit ベース)
• GitUI
• くすくす笑う

• SmartGit (Windows、Linux、Mac)
• GitKraken デスクトップ (Windows、Linux、Mac)
• Glint (Windows、Linux、Mac)

Eclipse Foundation は、毎年実施しているコミュニティ調査で、2014 年 5 月の時点で Git が最も広く使用されているソースコード管理ツールであると報告しており、プロのソフトウェア開発者の 42.9% が Git を主要なソース管理システムとして使用していると回答しています^{[98]。これは、2013 年の 36.3%、2012 年の 32% と比較して増加しています。また、} GitHubの使用を除いた Git の回答では、2014 年が 33.3%、2013 年が 30.3%、2012 年が 27.6%、2011 年が 12.8% となっています^[99] 。オープンソース ディレクトリのBlack Duck Open Hubは、オープンソース プロジェクト間で同様の採用が報告されています。^[100]

Stack Overflowは、 2015年（16,694件の回答）[101]、2017^年（ 30,730件の回答）^[102] 、 2018年（74,298件の回答）^[104]、2022年（71,379件の回答）^[15]の年次開発者調査にバージョン管理を含めています。これらの調査では、回答した開発者の間でGitが圧倒的に人気があり、2022年には93.9%という高い回答が寄せられました。

回答した開発者が使用したバージョン管理システム:

英国のIT求人サイトitjobswatch.co.ukの報告によると、2016年9月下旬の時点で、英国の常勤ソフトウェア開発職の29.27%がGitを挙げており、^[105] Microsoft Team Foundation Serverが12.17% 、^[106] Subversionが10.60% 、^[107] Mercurialが1.30% 、^[108] Visual SourceSafeが0.48%となっている。^[109]

Git 拡張機能は数多くあります。たとえば、Git LFS は GitHub コミュニティで Git の拡張機能として始まり、現在では他のリポジトリでも広く使用されています。拡張機能は通常、さまざまな人々によって個別に開発および保守されていますが、将来のある時点で、広く使用されている拡張機能が Git に統合される可能性があります。

その他のオープンソース Git 拡張機能には次のものがあります。

• git-annex、Git ベースの分散ファイル同期システム
• git-flow は、Vincent Driessen のブランチ モデルに高レベルのリポジトリ操作を提供する Git 拡張機能のセットです。
• git-machete、リポジトリオーガナイザーおよびリベース/マージ/プル/プッシュ操作を自動化するツール

Microsoftは、2017年のPerforceからの移行の一環として、Windowsソースコードツリーのサイズを処理するためのVirtual File System for Git （VFS for Git、以前はGit Virtual File SystemまたはGVFS）拡張機能を開発しました。VFS for Gitを使用すると、クローンされたリポジトリでプレースホルダーを使用でき、その内容はファイルにアクセスしたときにのみダウンロードされます。^[110]

Git はさまざまな方法で使用できますが、一般的に採用されている規則がいくつかあります。

• ローカルリポジトリを作成するコマンドgit init は、 masterという名前のブランチを作成します。^{[61] [111]}これは、変更をマージするための統合ブランチとしてよく使用されます。^[112]デフォルトのアップストリームリモートはoriginという名前であるため、^[113]デフォルトのリモートブランチはorigin/masterです。 GitHubやGitLabなどの一部のツールは、代わりにmainという名前のデフォルトブランチを作成します。^{[114] [115]}また、ユーザーはブランチを追加および削除したり、統合するブランチを選択したりできます。
• プッシュされたコミットは通常は上書きされず、以前のコミットを元に戻す別の変更をコミットすることで元に戻されます^[116]。これにより、共有コミットのベースとなるコミットがリモートに存在しないために、共有コミットが無効になることを防ぎます。コミットに機密情報が含まれている場合は、履歴を書き換えるためのより複雑な手順を伴い、コミットを削除する必要があります。
• git -flow ^[117]のワークフローと命名規則は、機能固有の不安定な履歴（feature/*）、不安定な共有履歴（develop）、本番環境対応の履歴（main）、リリースされた製品への緊急パッチ（hotfix）を区別するためによく採​​用されます。
• プルリクエスト（マージリクエストとも呼ばれる）は、ユーザーによるブランチを別のブランチにマージするためのリクエストです。^{[118] [119]} Git自体はプルリクエストを提供していませんが、これはgitクラウドサービスの一般的な機能です。プルリクエストの基本的な機能は、リポジトリの管理者が別のリモート（プルリクエストのソースであるリポジトリ）から変更をプルする機能と変わりません。ただし、プルリクエスト自体は、これらのアクションを実行するホスティングサーバーによって管理されるチケットであり、git SCMの機能ではありません。

Gitはアクセス制御のメカニズムを提供していませんが、アクセス制御に特化した他のツールと連携して操作できるように設計されています。^[120]

2014 年 12 月 17 日、Git クライアントのWindows 版とmacOS版に影響を与えるエクスプロイトが見つかりました。攻撃者は、攻撃者が作成したリポジトリまたは攻撃者が変更できるリポジトリに、 .git /hooks サブディレクトリ (Git が実行する実行ファイルを含むフォルダ) 内の悪意のあるファイルを含む、別の大文字/小文字 (.GIT や .Git など。Git では、すべて小文字のバージョンの.git を手動で作成できないため必要) で .git (リポジトリのすべてのデータを格納する Gitリポジトリ内のディレクトリ) という名前の悪意のある Git ツリー (ディレクトリ) を作成することにより、Git がインストールされているターゲット コンピュータで任意のコード実行を実行できます。 Windows または Mac ユーザーが悪意のあるディレクトリを含むリポジトリのバージョンをプル(ダウンロード) し、そのディレクトリに切り替えると、.git ディレクトリが上書きされ (Windows および Mac のファイルシステムでは大文字と小文字が区別されないため) 、.git/hooks内の悪意のある実行ファイルが実行される可能性があり、その結果、攻撃者のコマンドが実行されることになります。攻撃者は.git/config構成ファイルを変更することもできます。これにより、攻撃者は悪意のある Git エイリアス (Git コマンドまたは外部コマンドのエイリアス) を作成したり、既存のエイリアスを変更して実行時に悪意のあるコマンドを実行したりすることができます。この脆弱性は、2014 年 12 月 17 日にリリースされ、翌日に発表された Git バージョン 2.2.1 で修正されました。^{[121] [122]}

2015年9月29日にリリースされたGitバージョン2.6.1には、任意のコード実行を可能にするセキュリティ脆弱性（CVE-2015-7545）^[123]に対するパッチが含まれていました。^[124]任意のコマンドがURL自体に埋め込まれていたため、攻撃者が被害者に特定のURLを複製するよう説得できれば、この脆弱性を悪用することが可能でした。^[125]接続が暗号化されていない場合、攻撃者は中間者攻撃を介してこの脆弱性を悪用することができ、 ^[125]攻撃者はユーザーを任意のURLにリダイレクトすることができます。再帰クローンも、リポジトリのコントローラーがgitmodulesファイルを介して任意のURLを指定できるため、脆弱でした。^[125]

Gitは内部的にSHA-1ハッシュを使用しています。Linus Torvaldsは、ハッシュは主に偶発的な破損を防ぐためのものであり、暗号的に安全なハッシュが提供するセキュリティは単なる偶発的な副作用であり、主なセキュリティは他の場所での署名にあると回答しました。^{[126] [ 127 ] 2017年にgitに対する}SHAttered攻撃のデモンストレーションが行われて以来、gitはこの攻撃に耐性のあるSHA-1バリアントを使用するように変更されました。ハッシュ関数の移行計画は2020年2月から作成されています。^[128]

「Git」は、2015 年 2 月 3 日より US500000085961336 で Software Freedom Conservancyの登録商標です。

• ソースコードホスティング施設の比較
• バージョン管理ソフトウェアの比較
• バージョン管理ソフトウェアの一覧

• 公式サイト

WikibooksにはGitに関する本があります。

Wikimedia Commons にはGitに関連するメディアがあります。