Gitとは何か？

docs.scrimba.com

ほぼ確実に、あなたは手動でバージョン管理をしたことがあるはずです。report.docx、report_final.docx、report_final_v2.docx、report_final_ACTUAL.docxというファイルが入ったフォルダは、バージョン管理です。ただし、考えられる最悪の種類のバージョン管理です。2つのファイル間で何が変わったかを判断することはできませんし、2人が同時に加えた編集をマージすることもできません。さらに、3つ前のコピーで削除した良い段落を取り戻すこともできません。

Gitはその問題を適切に解決します。これはあなたのプロジェクトのスナップショットを時系列で記録するツールで、複数のコピーの山の代わりに、プロジェクト全体の履歴が1つの場所にあります。このツール自体はあなた自身のコンピュータ上に存在する小さなプログラムです。gitで始まるコマンドをターミナルに入力すると、テキストで応答します。

Gitがあなたのためにすること

本質的に、Gitはあなたのプロジェクトのタイムラインを保持します。保存する価値がある時点に達するたびに、**コミット**を記録します。これはすべてのファイルのスナップショットと、何が変わり、なぜ変わったかを説明する短いメッセージです。後でそのタイムラインを見返すことで、プロジェクトがどのようにして現在の状態に至ったかを正確に確認できます。これは実際のタイムラインで、git logで出力されます。これはプロジェクトのコミットを一覧表示するコマンドです（--onelineフラグはそれぞれを1行に短縮します）：

$ git log --oneline
a1b2c3d パスワード強度メーターを追加
9f8e7d6 サインアップフォームの検証を修正
5c4b3a2 プロジェクト構造をセットアップ

これはプロジェクトの履歴における3つの保存されたポイントで、最新が上にあり、それぞれに短いIDと作成者が書いたメッセージがあります。（このような例では、$で始まる行はターミナルに入力されたコマンドで、$自体は含まれません。その下の行はGitの応答です。）次の数章で、この履歴を生成および読み取るすべてのコマンドを学びます。今のところ、Gitが常に戻ることができるスナップショットシリーズとしてあなたの仕事を記録しているという考えを忘れずに。

プロジェクトがこのような履歴を持つと、多くのことが可能になります。何が変わり、誰が変えたかを見ることができます。危険な考えを脇に試してみて、うまくいかなかった場合はきれいに捨てることができます。プロジェクト全体とその完全な履歴を他の人に渡すことができます。2人が同じコードを編集するとき、Gitは彼らの仕事を組み合わせ、彼らが意見の相違がある場所にフラグを立てるので、人間がそれを解決できます。これらの4つの能力（履歴、安全な実験、共有、作業の組み合わせ）が、ほぼすべての専門的なコードベースの下でGitが実行されている理由全体です。

実際には、チームはそのタイムラインに絶えず依存しています。あらゆるサイズの変更は、独自のブランチから始まります。これはメインコードに支障をきたさずに作業できる独立した履歴線です。変更の準備ができたら、誰かがそれをレビューし、その後メインブランチにマージされます。レビュー、ブランチ化、マージはGitで作業する日々のリズムで、それらはすべて上記のスナップショットタイムラインに基づいています。このハンドブックの残りの部分は、そのリズムの各部分を出会う順序で説明します。

後で重要になる1つの詳細があります。各コミットは、追跡されたファイルの完全な状態、つまりその瞬間の完全なスナップショットを格納します。人々はGitが異なるバージョン間の差分のみを保存していると考えることが多いですが、実際には各コミットはプロジェクト全体を保持しています。Gitは各一意ファイルのコンテンツを一度だけ保存することでそれを安く保つため、変更されていないファイルを再利用するコミットは既に保存されたコピーを指すだけで、1つ変更されたファイルを含む1000ファイルのスナップショットは他の999を複製しません。各コミットは、その前に来たコミット（その親）のIDも記録します。これはGitがスナップショットを履歴にリンクして後方に歩く方法です。その親リンクはほぼすべての他のもののバックボーンです。ブランチ、マージ、履歴ブラウジングはすべてそれらのポインタをたどることに基づいています。履歴とブランチの章で完全なオブジェクトモデルを見ることができます。

JunoGitがあなたのためにすること Gitはあなたのプロジェクトをコミットと呼ばれるスナップショットのシリーズとして記録し、それぞれに何が変わったかを説明するメッセージがあります。その履歴が存在すると、それを見返したり、安全に実験したり、共有したり、他の人と協力して作業を組み合わせることができます。final_v2_ACTUALコピーの山はGitが終わらせるために構築された問題で、最初に1つを削除するときどれだけ素晴らしいかを約束します。

JunoGitがあなたのためにすること コミットはスナップショットプラスメッセージで、履歴はそれらのタイムラインです。日常的には、そのタイムラインからブランチを作成して変更を加え、レビューを受けて、マージして戻します。スナップショットの成長するタイムラインのメンタルモデルを頭に保ちます。学ぶすべてのコマンドは、それにそれを追加または読み取っています。

JunoGitがあなたのためにすること 各コミットはプロジェクト全体の状態を格納し、親を指します。これはGitが履歴を歩く方法です。同一のファイルコンテンツは1回保存され、コミット間で共有されるため、スナップショットは安いままです。親ポインタの考えを保ちます。ブランチとマージは異なる帽子をかぶった同じ考えです。

GitとGitHubは異なるもの

これは最初のころにほぼ誰もがつまずくので、ここに簡潔に述べます。Gitはバージョン管理ツールです。あなた自身のコンピュータ上で実行され、コミットを記録し、インターネット接続やアカウントは必要ありません。**GitHub**はGitリポジトリをオンラインで保存し、その周りに物を追加するウェブサイトです。コードを共有し、互いの変更をレビューし、問題を報告し、協力するための場所です。

違いを最も明確に感じる方法は、GitHubアカウントを作成せずに毎日Gitを使用し、ラップトップでコミットとブランチを作成することです。GitHubが登場するのは、リポジトリを他の人や他のマシンが到達できる共有場所に配置したいときだけです。Gitはエンジン。GitHubはそれが生産するものをホストする1つの場所です。他にも存在します。GitLabやBitbucketのような他のものも、その下で同じGitリポジトリをホストしています。

2つがまとめてぼやける理由は、ほとんどの人がGitとGitHubに同時に出会うためです。最初の日にGitHubからプロジェクトをクローンします。多くの人はgit pushが「GitHubに送信」を意味すると考えています。実際には、「設定したリモートに送信」を意味し、そのリモートはほとんどの時間GitHubです。2つを頭の中で分離して保つことは、異なるホストでGitを使用する場合、またはホストがない場合の最初の時間に報酬を支払います。

JunoGitとGitHubは異なるもの Gitはあなたのコンピュータ上のツールで、コミットを記録します。GitHubは、人々が共有およびレビューできるようにGitプロジェクトをオンラインで保存するウェブサイトです。GitHubアカウントなしでGitを使用できます。このページから1つのことを覚えておく場合は、これを覚えておいてください。なぜなら、それらを混ぜることで多くの初期の混乱が生じるからです。

JunoGitとGitHubは異なるもの Gitはあなたのマシン上のバージョン管理エンジン。GitHubはGitLabやBitbucketと並んで、それが生産するものをホストするための1つの一般的な場所です。git pushは、設定した任意のリモートに送信します。ほぼ確実にGitHubです。分割を保つと、プロジェクトが他の場所に存在する場合は投げられません。

JunoGitとGitHubは異なるもの Gitはコミット、ブランチ、およびrefsについて知っています。GitHubは、ホストされたコピーの上にプルリクエスト、問題、およびマージボタンをレイヤー化します。GitHubが追加するものは何もGitコマンドではありません。そのため、プルリクエストをウェブサイトで開いて、gitで開くことはありません。2つを頭の中で分離して、GitHubの魔法に見える大部分は通常のrefsに戻ります。

Gitの出来方

Gitの歴史は、それがなぜそのように機能するかを説明する多くを説明しています。これは2005年にLinux Torvaldsによって書かれました。Linuxを始めたのと同じ人です。Linuxカーネルは世界中に散らばった数千のボランティアによって構築されており、数年間、BitKeeperと呼ばれる商用ツールを使用してすべての作業を調整していました。その背後にある会社は、オープンソースプロジェクトが無料で使用できます。

2005年、その無料の取り決めは崩れ、カーネルコミュニティは突然、その大規模で急速に変化するコードベースを管理するツールがありませんでした。当時利用可能な他に何もカーネルのサイズに対応できませんでした。そこでTorvaldsはカーネル作業から2、3週間戻り、正確にその問題によって形作られたいくつかの堅固な目標で独自のバージョン管理ツールを書きました。

彼は**分散させたかったので、すべての貢献者が自分のマシンでプロジェクト履歴全体を持ち、中央サーバーをチェックインせずに作業できます。彼はそれを高速にしたかった。カーネルのサイズのプロジェクトを処理するのに十分な速さで、人々を待つことはなかった。また、彼は整合性**を保証したかったため、誰も静かに履歴を変更することはできず、ディスクエラーがプロジェクトを破損して気付かなくなることができません。

これらの目標が今日のGitがなぜそのように振る舞うかです。プロジェクトをcloneすると、その完全な履歴を使用して作業を得ます。これは分散目標の実際のアクションです。wi-fiなしで飛行機でコミット、ブランチ、およびブラウズ履歴を作成できます。すべてのコミットは、その正確なコンテンツから計算されたフィンガープリントでスタンプされるため、1バイトが変わると、フィンガープリントはマッチングを停止し、Gitはそれに気付きます。Torvaldsが2005年の急ぎで行った設計上の決定は、あなたが今Gitを使用するたびに依存している決定です。

整合性保証は全体の設計を駆動します。各コミットは、コミットの完全なコンテンツから計算されたハッシュ、固定長フィンガープリントで識別されます。親のIDが子のハッシュに供給されるため、ハッシュはチェーンを形成します。古いコミットで何かを変更して、そのハッシュを変更し、その後のすべてのコミットのハッシュを変更します。これはGit履歴を改ざん検出にするものです。また、コミットのIDがその正確なコンテンツのフィンガープリントであるため、a1b2c3dのような16進数の文字列の代わりに、きちんとしたコミット番号42を見る代わりに、見ることができます。

JunoGitの出来方 Linus Torvaldsは、プロジェクトが使用していたツールが無料になった後、2005年のLinuxカーネル用にGitを書きました。彼はそれを分散、高速、腐敗に対して安全にするために構築しました。これが、cloneがオフラインで作業する完全な履歴を提供し、なぜすべてのコミットがフィンガープリントを取得する理由です。何年も使用するツールのための便利なコンテキスト。

JunoGitの出来方 Gitは2005年のLinuxカーネルから出ました。中央サーバーなしで数千の貢献者用に構築されました。これが、その全体的なモデルが分散しているなぜです。すべてのクローンは完全な履歴を運びます。ローカルにブランチとコミットを行い、選択したときに同期します。Gitのデフォルトが奇妙に感じられたら、「それはカーネル用に設計されました」は通常それを説明しています。

JunoGitの出来方 Gitは、2005年にTorvaldsが2週間スプリントを行いました。カーネルはBitKeeperへのアクセスを失ったときです。3つの目標を持っています。分散、高速、整合性チェック。各コミットのハッシュはそのコンテンツとその親のハッシュから計算されるため、IDは改ざん検出チェーンを形成します。Gitがいくつかの選択をした理由について疑問に思ったら、「それはLinuxカーネル用に構築されました」は通常答えです。

このハンドブックは次に進みます

メンタルモデルを整備すると、トラックの残りは仕事についてです。あなたの最初のリポジトリはゼロから始まります。ターミナルを開き、マシンがGitを持たない場合はGitをインストールし、フォルダをコミットできるリポジトリに変えます。そこから、変更を保存する毎日のループ、その後ブランチ、マージ、およびGitHubの協力フローを学びます。用語があなたを失うことがあれば、用語集にはこれらのドキュメント内のGit語彙のすべての部分の短い定義があります。