![\"xkcd](\"https://imgs.xkcd.com/comics/git.png\")
バージョン管理システム(VCS)は、ソースコード(または他のファイルやフォルダのコレクション)への変更を追跡するために使用されるツールです。名前が示すように、これらのツールは変更の履歴を維持するのに役立ちます。さらに、コラボレーションを促進します。VCSは、フォルダとその内容への変更を一連のスナップショットで追跡します。各スナップショットは、トップレベルディレクトリ内のファイル/フォルダの全体的な状態をカプセル化します。VCSは、各スナップショットを作成した人、各スナップショットに関連付けられたメッセージなどのメタデータも維持します。
\n\nなぜバージョン管理は便利なのでしょうか?一人で作業している場合でも、プロジェクトの古いスナップショットを見たり、特定の変更が行われた理由のログを保持したり、並行する開発ブランチで作業したりすることができます。他の人と作業する場合、他の人が何を変更したかを確認したり、並行開発での競合を解決したりするための非常に貴重なツールです。
\n\n最新のVCSでは、次のような質問に簡単に(そしてしばしば自動的に)答えることもできます:
\n\n他のVCSも存在しますが、Gitはバージョン管理の事実上の標準です。このXKCDコミックは、Gitの評判を捉えています:
\n\n
Gitのインターフェースは抽象化が漏れているため、Gitをトップダウン(インターフェース/コマンドラインインターフェースから始める)で学ぶと、多くの混乱を招く可能性があります。一握りのコマンドを暗記して、それらを魔法の呪文のように考え、何か問題が起きたときは上記のコミックのアプローチに従うことは可能です。
\n\nGitは確かに醜いインターフェースを持っていますが、その基礎となる設計とアイデアは美しいものです。醜いインターフェースは暗記しなければなりませんが、美しい設計は理解することができます。このため、Gitのボトムアップの説明を提供し、データモデルから始めて、後でコマンドラインインターフェースをカバーします。データモデルが理解されれば、コマンドが基礎となるデータモデルをどのように操作するかという観点から、コマンドをよりよく理解できます。
\n\nバージョン管理には、多くのアドホックなアプローチがあります。Gitには、履歴の維持、ブランチのサポート、コラボレーションの実現など、バージョン管理のすべての優れた機能を可能にする、よく考えられたモデルがあります。
\n\nGitは、トップレベルディレクトリ内のファイルとフォルダのコレクションの履歴を、一連のスナップショットとしてモデル化します。Gitの用語では、ファイルは「blob」と呼ばれ、単なるバイトの集まりです。ディレクトリは「tree」と呼ばれ、名前をblobまたはtreeにマッピングします(したがって、ディレクトリは他のディレクトリを含むことができます)。スナップショットは、追跡されているトップレベルのtreeです。たとえば、次のようなtreeがあるとします:
\n\n<root> (tree)\n|\n+- foo (tree)\n| |\n| + bar.txt (blob, contents = \"hello world\")\n|\n+- baz.txt (blob, contents = \"git is wonderful\")\nトップレベルのtreeには2つの要素が含まれています。tree「foo」(それ自体が1つの要素、blob「bar.txt」を含む)と、blob「baz.txt」です。
\n\nバージョン管理システムはスナップショットをどのように関連付けるべきでしょうか?1つの単純なモデルは、線形の履歴を持つことです。履歴は時系列のスナップショットのリストになります。多くの理由から、Gitはこのような単純なモデルを使用しません。
\n\nGitでは、履歴はスナップショットの有向非巡回グラフ(DAG)です。これは難しい数学用語のように聞こえるかもしれませんが、怖がる必要はありません。これが意味するのは、Gitの各スナップショットが「親」のセット、つまりそれに先行するスナップショットを参照するということです。線形履歴の場合のように単一の親ではなく親のセットである理由は、スナップショットが複数の親から派生する可能性があるためです。たとえば、2つの並行する開発ブランチを結合(マージ)する場合などです。
\n\nGitはこれらのスナップショットを「commit」と呼びます。コミット履歴を視覚化すると、次のようになります:
\n\no <-- o <-- o <-- o\n ^\n \\\n --- o <-- o\n上記のASCIIアートでは、oは個々のコミット(スナップショット)に対応しています。矢印は各コミットの親を指しています(「後に来る」ではなく「前に来る」関係です)。3番目のコミットの後、履歴は2つの別々のブランチに分岐します。これは、たとえば、2つの別々の機能が互いに独立して並行して開発されていることに対応する可能性があります。将来、これらのブランチはマージされて、両方の機能を組み込んだ新しいスナップショットを作成し、次のような新しい履歴を生成する可能性があります。新しく作成されたマージコミットは太字で示されています:
\n\no <-- o <-- o <-- o <---- o\n ^ /\n \\ v\n --- o <-- o\n\n\n\nGitのコミットは不変です。これは、間違いを修正できないという意味ではありません。コミット履歴への「編集」は、実際には完全に新しいコミットを作成し、参照(以下を参照)が新しいコミットを指すように更新されるだけです。
\n\nGitのデータモデルを疑似コードで書き下すと、理解しやすいかもしれません:
\n\n// ファイルはバイトの集まり\ntype blob = array<byte>\n\n// ディレクトリには名前付きファイルとディレクトリが含まれる\ntype tree = map<string, tree | blob>\n\n// コミットには親、メタデータ、トップレベルのtreeがある\ntype commit = struct {\n parents: array<commit>\n author: string\n message: string\n snapshot: tree\n}\nこれは、クリーンでシンプルな履歴のモデルです。
\n\n「オブジェクト」は、blob、tree、またはcommitです:
\n\ntype object = blob | tree | commit\nGitデータストアでは、すべてのオブジェクトはSHA-1ハッシュによってコンテンツアドレス指定されます。
\n\nobjects = map<string, object>\n\ndef store(object):\n id = sha1(object)\n objects[id] = object\n\ndef load(id):\n return objects[id]\nBlob、tree、commitはこのように統一されています:それらはすべてオブジェクトです。他のオブジェクトを参照する場合、ディスク上の表現に実際にそれらを含むのではなく、ハッシュによってそれらへの参照を持ちます。
\n\nたとえば、上記のディレクトリ構造例のtree(git cat-file -p 698281bc680d1995c5f4caaf3359721a5a58d48dを使用して視覚化)は、次のようになります:
100644 blob 4448adbf7ecd394f42ae135bbeed9676e894af85 baz.txt\n040000 tree c68d233a33c5c06e0340e4c224f0afca87c8ce87 foo\ntree自体には、その内容へのポインタ、baz.txt(blob)とfoo(tree)が含まれています。git cat-file -p 4448adbf7ecd394f42ae135bbeed9676e894af85でbaz.txtに対応するハッシュによってアドレス指定された内容を見ると、次のようになります:
git is wonderful\n現在、すべてのスナップショットはSHA-1ハッシュで識別できます。これは不便です。なぜなら、人間は40文字の16進数文字列を覚えるのが得意ではないからです。
\n\nこの問題に対するGitの解決策は、SHA-1ハッシュの人間が読める名前で、「参照」と呼ばれます。参照はコミットへのポインタです。不変であるオブジェクトとは異なり、参照は可変です(新しいコミットを指すように更新できます)。たとえば、master参照は通常、開発のメインブランチの最新のコミットを指します。
references = map<string, string>\n\ndef update_reference(name, id):\n references[name] = id\n\ndef read_reference(name):\n return references[name]\n\ndef load_reference(name_or_id):\n if name_or_id in references:\n return load(references[name_or_id])\n else:\n return load(name_or_id)\nこれにより、Gitは長い16進数文字列の代わりに、「master」のような人間が読める名前を使用して、履歴内の特定のスナップショットを参照できます。
\n\n1つの詳細は、新しいスナップショットを取得するときに、それが何に対して相対的であるかを知るために(コミットのparentsフィールドをどのように設定するか)、履歴内の「現在どこにいるか」という概念が必要になることがよくあります。Gitでは、その「現在どこにいるか」は「HEAD」と呼ばれる特別な参照です。
最後に、Gitリポジトリとは何か(大まかに)を定義できます:それはデータobjectsとreferencesです。
ディスク上で、Gitが保存するのはオブジェクトと参照だけです:それがGitのデータモデルのすべてです。すべてのgitコマンドは、オブジェクトを追加したり、参照を追加/更新したりすることによって、コミットDAGの何らかの操作にマッピングされます。
コマンドを入力するときは常に、コマンドが基礎となるグラフデータ構造に対してどのような操作を行っているかを考えてください。逆に、コミットDAGに特定の種類の変更を加えようとしている場合、たとえば「コミットされていない変更を破棄し、'master'参照をコミット5d83f9eを指すようにする」場合、おそらくそれを行うコマンドがあります(たとえば、この場合はgit checkout master; git reset --hard 5d83f9e)。
これは、データモデルとは直交する別の概念ですが、コミットを作成するためのインターフェースの一部です。
\n\n上記で説明したスナップショットを実装する1つの方法は、作業ディレクトリの現在の状態に基づいて新しいスナップショットを作成する「スナップショットの作成」コマンドを持つことです。一部のバージョン管理ツールはこのように機能しますが、Gitは違います。クリーンなスナップショットが必要であり、現在の状態からスナップショットを作成することが常に理想的であるとは限りません。たとえば、2つの別々の機能を実装し、2つの別々のコミットを作成したいシナリオを想像してください。最初のコミットは最初の機能を導入し、次のコミットは2番目の機能を導入します。または、コードのあちこちにデバッグ用のprint文を追加し、バグ修正も行ったシナリオを想像してください。print文をすべて破棄しながら、バグ修正をコミットしたいとします。
\n\nGitは、「ステージングエリア」と呼ばれるメカニズムを通じて、次のスナップショットに含める変更を指定できるようにすることで、このようなシナリオに対応します。
\n\n情報の重複を避けるため、以下のコマンドを詳細に説明しません。詳細については、強く推奨されるPro Gitを参照してください。
\n\ngit initコマンドは、新しいGitリポジトリを初期化し、リポジトリのメタデータは.gitディレクトリに保存されます:
$ mkdir myproject\n$ cd myproject\n$ git init\nInitialized empty Git repository in .git\n$ git status\nOn branch master\nNo commits yet\nnothing to commit (create/copy files and use \"git add\" to track)\nこの出力をどのように解釈すればよいでしょうか?「No commits yet」は基本的に、バージョン履歴が空であることを意味します。それを修正しましょう。
\n\n$ echo \"hello, git\" > hello.txt\n$ git add hello.txt\n$ git status\nOn branch master\nNo commits yet\nChanges to be committed:\n (use \"git rm --cached <file>...\" to unstage)\n new file: hello.txt\n$ git commit -m 'Initial commit'\n[master (root-commit) 4515d17] Initial commit\n 1 file changed, 1 insertion(+)\n create mode 100644 hello.txt\nこれで、ファイルをステージングエリアにgit addし、その変更をgit commitして、シンプルなコミットメッセージ「Initial commit」を追加しました。-mオプションを指定しなかった場合、Gitはテキストエディタを開いてコミットメッセージを入力できるようにします。
これで空でないバージョン履歴ができたので、履歴を視覚化できます。履歴をDAGとして視覚化することは、リポジトリの現在の状態を理解し、Gitデータモデルの理解と結びつけるのに特に役立ちます。
\n\ngit logコマンドは履歴を視覚化します。デフォルトでは、グラフ構造を隠したフラット化されたバージョンを表示します。git log --all --graph --decorateのようなコマンドを使用すると、リポジトリの完全なバージョン履歴がグラフ形式で視覚化されて表示されます。
$ git log --all --graph --decorate\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa (HEAD -> master)\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nこれは、単一のノードしか含まれていないため、あまりグラフのようには見えません。さらにいくつかの変更を加え、新しいコミットを作成し、もう一度履歴を視覚化してみましょう。
\n\n$ echo \"another line\" >> hello.txt\n$ git status\nOn branch master\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git checkout -- <file>...\" to discard changes in working directory)\n modified: hello.txt\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add hello.txt\n$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD <file>...\" to unstage)\n modified: hello.txt\n$ git commit -m 'Add a line'\n[master 35f60a8] Add a line\n 1 file changed, 1 insertion(+)\n今度は、履歴を再度視覚化すると、グラフ構造の一部が表示されます:
\n\n* commit 35f60a825be0106036dd2fbc7657598eb7b04c67 (HEAD -> master)\n| Author: Subramanya N <subramanyanagabhushan@gmail.com>\n| Date: Tue Dec 21 22:26:20 2020 -0500\n| Add a line\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nまた、現在のHEADと現在のブランチ(master)が表示されていることに注意してください。
\n\ngit checkoutコマンドを使用して、古いバージョンを見ることができます。
$ git checkout 4515d17 # 以前のコミットハッシュ;あなたのものは異なります\nNote: checking out '4515d17'.\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by performing another checkout.\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -b with the checkout command again. Example:\n git checkout -b <new-branch-name>\nHEAD is now at 4515d17 Initial commit\n$ cat hello.txt\nhello, git\n$ git checkout master\nPrevious HEAD position was 4515d17 Initial commit\nSwitched to branch 'master'\n$ cat hello.txt\nhello, git\nanother line\nGitは、git diffコマンドを使用して、ファイルがどのように進化したか(差分、またはdiff)を表示できます:
$ git diff 4515d17 hello.txt\ndiff --git c/hello.txt w/hello.txt\nindex 94bab17..f0013b2 100644\n--- c/hello.txt\n+++ w/hello.txt\n@@ -1 +1,2 @@\n hello, git\n +another line\ngit help <command>: gitコマンドのヘルプを取得git init: 新しいgitリポジトリを作成し、データは.gitディレクトリに保存されますgit status: 何が起こっているかを教えてくれますgit add <filename>: ファイルをステージングエリアに追加git commit: 新しいコミットを作成\ngit log: 履歴のフラット化されたログを表示git log --all --graph --decorate: 履歴をDAGとして視覚化git diff <filename>: ステージングエリアに対して行った変更を表示git diff <revision> <filename>: スナップショット間のファイルの差分を表示git checkout <revision>: HEADと現在のブランチを更新ブランチを使用すると、バージョン履歴を「フォーク」できます。独立した機能やバグ修正を並行して作業するのに役立ちます。git branchコマンドを使用して新しいブランチを作成できます。git checkout -b <branch name>はブランチを作成してチェックアウトします。
マージはブランチの反対です:フォークされたバージョン履歴を結合できます。たとえば、機能ブランチをmasterにマージして戻します。git mergeコマンドがマージに使用されます。
git branch: ブランチを表示git branch <name>: ブランチを作成git checkout -b <name>: ブランチを作成して切り替え\ngit branch <name>; git checkout <name>と同じgit merge <revision>: 現在のブランチにマージgit mergetool: マージコンフリクトの解決を支援する便利なツールを使用git rebase: パッチのセットを新しいベースにリベースgit remote: リモートをリストgit remote add <name> <url>: リモートを追加git push <remote> <local branch>:<remote branch>: オブジェクトをリモートに送信し、リモート参照を更新git branch --set-upstream-to=<remote>/<remote branch>: ローカルブランチとリモートブランチの対応を設定git fetch: リモートからオブジェクト/参照を取得git pull: git fetch; git mergeと同じgit clone: リモートからリポジトリをダウンロードgit commit --amend: コミットの内容/メッセージを編集git reset HEAD <file>: ファイルをアンステージgit checkout -- <file>: 変更を破棄git config: Gitは高度にカスタマイズ可能ですgit clone --depth=1: バージョン履歴全体なしのシャロークローンgit add -p: インタラクティブなステージングgit rebase -i: インタラクティブなリベースgit blame: どの行を誰が最後に編集したかを表示git stash: 作業ディレクトリへの変更を一時的に削除git bisect: 履歴のバイナリサーチ(たとえば、リグレッション用).gitignore: 意図的に追跡されないファイルを無視するように指定