1 はじめに

git は複数人でプログラム （あるいは文章）を作ることを目的として作られた プログラムです。

わたしは 基本的に git を 「お一人様 git」としてしか使っていません。 それでも git はとても役にたつプログラムです。 「お一人様 git 」の使い方を、今回と次回のメールでお伝えします。

まずは先日 clone してつくった naturalism ディ レクトリ（「ローカルの作業場所」）の中にはいっ てください（cd naturalism/）。

しばらく GitHub にある naturalism リポジト リ（「リモート・リポジトリ」）を忘れてくださ い。このメールではローカルな作業場所での作業 の仕方を説明します。

2 ローカルな作業場所

「ローカルな作業場所」とは、あなたの手元のコ ンピューターの naturalism/ ディレクトリです。 その中身をよく見ると .git/ という（サブ）ディ レクトリがあるのがわかると思います。（ウィン ドウズではドットで始まるファイル／ディレクト リを見るのは難しいと聞いたことがあります。見 当たらなくても、「そのような（隠し）ディレク トリがあるんだろう」として、以下の話を聞いて ください）。

この .git/ サブディレクトリ以下は 決してさわらないでください。 ここに（リモート・リポジトリに対応する）リポジトリがあります。 これを「ローカル・リポジトリ」と呼びます。

「ローカルな作業場所」でする作業（このメール で述べること）とは、そのディレクトリ内にある ファイルを編集して、それらの変更箇所をローカ ルなリポジトリに「コミットする／チェックイン する」ことです。

3 中間の舞台 (stage) とローカルリポジトリ

git の一つの捉え方は「執筆の際の心変わりを許 す」プログラムと言えます。論文やプログラムは、 ある目論見で書き始めても、「あ・やっぱりこう ではない」と思うことがよくあります。そのよう な心変わりに対処できるのが git というプログラ ムです。

心変わり対策の第１弾が「中間の舞台」の設置で す。中間 とは「ローカルな作業場所」 と「ローカルなリポジトリ」の「中間」という意 味です。変更をローカルなリポジトリにコミット する前に、 並べておく場所です。

中間の舞台に登録するには git add コマンドを つかいます。

この中間舞台があることにより、最終的なローカルリポジトリに 登録するまえに考えることができます。

そして納得がいけば git commit コマンドで ローカルリポジトリに変更箇所をコミットします。

そして、コミットした後でも無理矢理に その変更を「なかったこと」にするコマンドも用意されています。

このへんの「やり直しコマンド」については、 git にもっとなれてからのほうがいいでしょう。 ここでは説明しません。

というわけで、（やり直しを考えなければ） foo.md というファイルの変更は、 まず git add foo.md で中間舞台に登録して、 つづいて、 git commit foo.md でローカルリポジトリに登録する、 という手順で行なうことになります。 （commit するときにメッセージが要求されます） メッセージをあとで入力するのが面倒であれば、 git commit foo.md -m "..." とします。 ... の部分にメッセージをかきます。

4 ブランチ

中間舞台とリポジトリでの やり直し ではない 方法、 とっておきの git の「心変わり」対策をお教えします。 それは「ブランチ」という考え方です。 実験的なブランチをつくって、そこで作業をして、 納得すれば、 そのブランチの作業をメインの流れに統合します。

     M1                     M2
---- o ----------------------o---
     |                       |
      +----o ---- o ----o----+
           T1    T2     T3

A1 まで作業をしているとしましょう。 そこで「こうしようか、ああしようか」迷ったとします。 そのような場合は、 迷わずブランチをつくりましょう（「ブランチを切る」というそうです）。 名前はなんでもいいですが、 ここでは test という名前としましょう。 git branch test で新しいブランチ test が作成されます。 そして、git checkout test で、 そのブランチに移動できます。 もとの状況にもどるには git checkout main とします。 （ブランチのもとになるのだから「幹」だろうと 思っていたかもしれませんが、 じつは、オリジナルの状況も main という名前のブランチだったのです）

なお、 以上の作業（git branch test および git checkout test）は、 git checkout -b test でも可能です。

さて、test ブランチで作業をして、 アッドとコミットを3回したとしましょう （T1、T2 および T3）。

この作業に満足ならばメインのブランチに統合します。 まず、メインのブランチに移動します (git checkout main)。 作業ディレクトリは M1 の状態となります。 そして、test ブランチをメインに融合（マージ）します (git merge test)。 メインの状況は M2 となります。

もし、ブランチでの作業が気にいらなければ、 git checkout main でメインに戻り（M1）、 以降は test ブランチには触れないようにすればいいでしょう。 削除する必要はありませんが、 どうしても削除したければ git branch -d test で、 test ブランチは削除されます。

git add や git commit したあとに 「やり直し」をするより、 ブランチをつかって、 さまざまな「やり直し」をするほうがわかりやすいと思います。 ここでは「ブランチ全体を採用するか否か」の場合だけを 取り上げましたが、 もっと細かく採用部分を指定できます （「さくらんぼ摘み」といいます）— その詳しいやりかたは、後日紹介します。

4.1 心得

「まよったらブランチを切る」という書き方をしましたが、 じつは、 git を使うときには、なにはともあれ「ブランチを切る」と 覚えておいたほうがいいでしょう。 安全のため、 そして後のさくらんぼ摘みのために、 とにかく、ブランチを切ってから作業をしましょう。

5 おまけ：便利なコマンド

add による中間の舞台への登録のやりなおし、 commit によるリポジトリへの登録のやりなおしについては、 別に述べます。 ここではそれとは別の、けっこうよく使うコマンドを紹介します。

5.1 stash （「わきにおいておく」）

じっさいにエディタで作業をしたけど、 add したくなくなったとします。 こんな時は git stash file_name としてください。 ファイルが中間の舞台の状況にもどります。 編集した部分はいらないでしょうから、 git stash clear してください。

5.2 checkout

stash は、いわば、中間の舞台にあるものを 作業ディレクトリにとりもどすコマンドでした。 リポジトリにあるものを作業ディレクトリに呼び戻すには git checkout をつかいます。

まちがえてファイルを削除してしまったとしましょう。 git checkout file_name で、 そのファイルのリポジトリにあるバージョンがよみがえります。