Gitバージョン管理システムの使い方を学ぶチュートリアルシリーズへようこそ！この記事では、Gitの用途と、Gitを使うべきユーザーについて学びます。

オープンソースの世界が初めての方であれば、Git でコードをホストしたり、使用バージョンを公開したりするオープンソースソフトウェアに遭遇する可能性が高いでしょう。実際、意識しているかどうかに関わらず、Git ベースのバージョン管理ソフトウェアを使用しています。Linux カーネル（スマートフォンやコンピューターで Linux を使用していなくても、アクセスするウェブサイトは Linux で動作しています）、Firefox、Chrome をはじめ、多くのプロジェクトが Git リポジトリを通じて世界中の開発者とコードを共有しています。

言い換えれば、Gitだけでコードを他の人と共有できるのでしょうか？自宅やオフィスでGitをプライベートに使うことはできるのでしょうか？Gitを使うにはGitHubアカウントが必要なのでしょうか？なぜGitを使うのでしょうか？Gitのメリットは何でしょうか？Gitしか選択肢がないのでしょうか？Gitに関するこれらの疑問は、私たちを混乱させる可能性があります。

では、これまで Git について知っていたことを忘れて、Git の世界に戻りましょう。

バージョン管理システムとは何ですか?

Gitは主にバージョン管理システムです。現在、市場にはCVS、SVN、Mercurial、Fossil、そしてもちろんGitなど、様々なバージョン管理システムが存在します。

GitHubやGitLabなどの多くのサービスはGitをベースにしていますが、追加のサービスなしでGit単体で使用することも可能です。つまり、Gitをプライベートでもパブリックでも使用できるということです。

電子文書で誰かと共同作業した経験があれば、従来のバージョン管理ワークフローに馴染みがあるでしょう。ワークフローはいたってシンプルです。まず、オリジナルのバージョンを作成し、それを同僚に送信します。同僚は受信したバージョンにいくつか変更を加え、2つのバージョンが作成されます。そして、同僚は修正版を返信します。返信された変更を自分のバージョンにマージすると、2つのバージョンが1つの更新されたバージョンに統合されます。

その後、あなたは自分の最新バージョンを修正し、同僚はマージ前のバージョンを修正しました。これで、最新のマージバージョン、あなたが修正したバージョン、そして同僚が修正を続けてきたバージョンの3つの異なるバージョンができました。この時点で、バージョン管理システムはますます混乱をきたしつつあります。

Jason van Gumster氏が記事で指摘しているように、アーティストでさえバージョン管理が必要であり、この傾向は既に一部の人々で確認されています。アーティストや科学者が実験的なバージョンを開発することは珍しくありません。プロジェクトでは、あるバージョンが大成功を収め、プロジェクトを新たな高みへと押し上げる一方で、別のバージョンが完全に失敗することもあります。そのため、project_justTesting.kdenlive、project_betterVersion.kdenlive、project_best_FINAL.kdenlive、project_FINAL-alternateVersion.kdenliveといった名前のファイルが大量に作成されることになります。

for ループを変更する場合でも、単純なテキスト編集を行う場合でも、優れたバージョン管理システムがあれば作業が楽になります。

Gitスナップショット

Git はプロジェクトのスナップショットを作成し、これらのスナップショットを一意のバージョンとして保存できます。

プロジェクトを間違った方向に進めてしまった場合は、以前の正しいバージョンに戻して、別の実行可能なアプローチを試すことができます。

開発で他の人と共同作業している場合、誰かが変更を送信してきたら、その変更を作業ブランチにマージすることができます。そうすると、同僚は最新のマージされたバージョンを取得して作業を続行できます。

Gitは魔法ではないので、競合は発生します（「ファイルの最後の行を変更したのに、行全体を削除してしまった。このような競合をどう処理すればいいの？」など）。しかし、Gitは基本的にすべての変更履歴を保存し、並列バージョンの作成も可能にします。これにより、競合を好きなように処理できるようになります。

分散Git

複数のマシンで同じプロジェクトに取り組むのは複雑なプロセスです。何か作業を始めると、プロジェクトの最新バージョンを入手し、それに基づいて変更を加え、最後に同僚と共有する必要があります。従来の方法では、面倒なオンラインファイル共有サービスや古いメール添付ファイルを使用する必要があり、どちらも非効率的でエラーが発生しやすいです。

Gitは本質的に分散作業向けに設計されています。プロジェクトに関わっている場合は、プロジェクトのGitリポジトリをクローンし、あたかも自分が唯一のローカルバージョンであるかのように変更を加えることができます。さらに、簡単なコマンドを使って、他の開発者の変更をプルしたり、自分の変更を他の開発者にプッシュしたりできます。これで、誰が最新バージョンを持っているか、各自のバージョンがどこに保存されているかを気にする必要がなくなります。全員がローカルで開発を行い、共通の目標（プロジェクトの開発アプローチによっては、共通の目標ではない目標もあるかもしれません）に向けて更新をプッシュまたはプルします。

Gitインターフェース

オリジナルのGitはLinuxターミナル上で動作するアプリケーションでした。しかし、Gitはオープンソースであり、優れた設計を備えているため、世界中の開発者がGitへの様々なアクセスインターフェースを設計できます。

Gitは完全に無料で、Linux、BSD、Illumos、その他のUnix系システム向けにパッケージ化されています。Gitコマンドは以下のようになります。

 $ git --version  
 git バージョン 2.5.3

Gitのインターフェースとして最もよく知られているのは、GitHub、オープンソースのGitLab、Savannah、BitBucket、SourceForgeといったWebベースのインターフェースでしょう。これらのサイトは、一般社会がアクセス可能なオープンソースソフトウェアのためのコードホスティングサービスを最大限に提供しています。ブラウザベースのグラフィカルインターフェース（GUI）は、ある程度、Gitの習得にかかる時間を大幅に短縮できます。以下はGitLabインターフェースのスクリーンショットです。

さらに、サードパーティのGitサービスプロバイダーや独立系開発者は、HTMLベースではなく、Git上にカスタマイズされたフロントエンドインターフェースを作成することもできます。これらのインターフェースにより、ブラウザを開かずにGitのバージョン管理を簡単に行うことができます。ユーザーにとって最も透過的な方法は、ファイルマネージャーとの直接統合です。KDEのDolphinファイルマネージャーは、ディレクトリ内のGitのステータスを直接表示し、コミット、プッシュ、プルの更新操作もサポートしています。

Sparkleshare は、Dropbox スタイルのファイル共有インターフェースの基盤として Git を使用します。

さらに詳しく知りたい場合は、Git のグラフィカル インターフェイス プロジェクトを多数紹介する (長い) ページである Git wiki をご覧ください。

Git を使うべき人は誰でしょうか?

以上です！もっと考えるべきことは、「Git をいつ使うべきか？」「Git を何のために使うべきか？」ということです。

Git はいつ使用すればよいですか? Git は何の目的で使用しますか?

Git をより深く学ぶには、通常よりもファイル形式について考慮する必要があります。

Gitはソースコード（ほとんどのプログラミング言語ではテキスト行）を管理するために設計されました。もちろん、Gitはあなたがそのテキストをソースコードとして扱っているのか、それとも次なるアメリカの傑作小説として扱っているのかを区別できません。したがって、ファイルの内容がテキストで構成されている限り、Gitを使ってバージョンを追跡・管理するのは良い選択です。

しかし、テキストとは一体何なのでしょうか？LibreOfficeのようなオフィスソフトウェアでコンテンツを編集する場合、通常はプレーンテキストコンテンツは生成されません。これは、複雑なアプリケーションでは、生のテキストコンテンツをXMLマークアップ言語でラップしてZipファイルに保存するなど、カプセル化することが多いためです。このカプセル化により、ファイルを他の人に送信した際に、オフィスソフトウェアで編集した内容や特定のテキスト効果を確認できます。皮肉なことに、KdenliveプロジェクトファイルやInkscapeからエクスポートしたSVGファイルの保存など、ニーズが複雑な場合が多いにもかかわらず、Gitを使用してXMLなどのプレーンテキストコンテンツを管理するのが最も簡単です。

Unix システムを使用している場合は、`file` コマンドを使用してファイルの内容を表示できます。

 $ ファイル ~/path/から/my-file.blahへ
my-file.blah: ASCIIテキスト
$ file ~/path/ to /different-file.kra: Zipデータ（MIMEタイプ"application/x-krita" ）

それでも不明な場合は、`head` コマンドを使用してファイルの内容を表示できます。

 $ head ~/path/を/my-file.blahへ移動

出力テキストを基本的に理解できる場合、そのファイルはテキストファイルである可能性が高いです。意味不明な文字列の中に、たまに見覚えのある文字がいくつか現れる程度であれば、そのファイルはテキストファイルではない可能性が高いです。

正確に言うと、Git は他のファイル形式も扱えますが、それらをバイナリラージオブジェクト（BLOB）として扱います。違いは、テキストファイルの場合、Git は2つのスナップショット（またはコミット）の間に3行が変更されたことを明示的に通知できる点です。しかし、2つのコミットの間に画像を編集した場合、Git はこの変更をどのように示すのでしょうか？実際には、画像は追加または削除可能な意味のあるテキストで構成されていないため、Git はこの変更を明示的に記述できません。もちろん、個人的には画像の編集が「<sky>ugly blue-green</sky>」というテキストを「<sky>sky blue with fluffy white clouds</sky>」に変更するのと同じくらい簡単であればいいのですが、現実には画像編集はそれほど簡単ではありません。

PNGアイコン、スプレッドシート、フローチャートなどの大きなバイナリBLOBファイルをGitに配置することはよくあります。Gitでこのような大きなファイルを管理するのは直感的ではないことは承知していますが、Gitを使って管理する必要がある場合は、それほど心配する必要はありません。プロジェクトでテキストファイルと大きなバイナリBLOBの両方が生成される場合（画像や音声素材がソースコードと同じくらい重要なビデオゲームの一般的なシナリオなど）、共有ネットワークドライブへの参照を使用するなど、独自のソリューションを開発するか、Joey Hessが開発したgit annexやGit-MediaプロジェクトなどのGitプラグインを使用するかの2つの選択肢があります。

Gitは本当に誰でも使えるツールです。ファイルのバージョン管理に使える強力で使いやすいツールで、最初に思うほど難しくはありません。