Gitの基本操作｜1人で使う分だけを先に覚えて手を動かす

git 基本 操作で検索して出てくるのは、たいてい20個ほどのコマンドが並んだ一覧です。困るのは、その一覧が「今日の作業でどれを打つのか」を教えてくれないところにあります。1人で書いているコードをバージョン管理したいだけの人と、チームのリポジトリに参加する人では、必要な操作の範囲がまったく違います。ここでは覚える順番を決めたうえで、ファイルがどの状態にあるかを読む力、実際に打つ流れ、そして間違えたときの戻し方を整理します。

最初に覚える範囲は5つに絞れる

公式の解説書の巻末は、Gitのコマンドをセットアップと設定、プロジェクトの取得と作成、基本的なスナップショット、ブランチとマージ、プロジェクトの共有とアップデート、検査と比較、デバッグ、パッチの適用、メール、外部システム、システム管理、配管コマンドという12の区分に並べています。日々の作業で打つのは、このうち上のいくつかだけです。学習の入口として挙げられている範囲は、おおむね次のように整理されています。

最低限覚えるべきコマンドは、git status（状態確認）、git add（ステージング追加）、git commit（変更記録）、git push（リモートへ送信）、git pull（リモートから取得）の5つです。これらを使いこなせれば基本的な開発作業は行えます。慣れてきたらgit branch、git switch、git mergeなどのブランチ操作も習得しましょう。 出典: itcross.jp

この5つで止めておく価値は、打つ回数の偏りにあります。1日の作業で状態を確かめるコマンドは何十回も打ちますが、履歴を組み替えるコマンドは月に数回も出てきません。頻度の高いものから体に入れたほうが、覚えた順に作業が楽になります。

身につくまでの時間についても、目安が示されています。基本的なコマンド操作であれば1〜2週間、コンフリクトの解決やプルリクエストの運用まで含めると1〜2ヶ月程度が目安とされています。初心者がつまずくのは操作の数ではなく、この後に説明する「いまファイルがどの状態にあるのか」が読めないところです。

ファイルは3つの状態を行き来している

Gitの公式の解説書は、作業中のファイルを追跡されているものと追跡されていないものに分け、追跡されているものをさらに3つの状態に分けています。

追跡されているファイルとは、直近のスナップショットに存在したファイルのことです。これらのファイルについては変更されていない(unmodified)」「変更されている(modified)」「ステージされている(staged)」の三つの状態があります。 出典: git-scm.com

この分け方が分かると、状態を確かめるコマンドの出力がそのまま読めるようになります。出力に並ぶ見出しは状態の名前と対応していて、追跡されていないファイルは Untracked files に、ステージしたものは Changes to be committed に、変更したがステージしていないものは Changes not staged for commit に出ます。どの見出しに名前があるかで、次に打つコマンドが決まります。

同じ資料は、追跡されていないファイルの扱いについても理由を書いています。明示的に指示しない限りGitはコミット時にそのファイルを含めないため、自動生成されたバイナリファイルを間違えてコミットする心配がない、という設計です。ビルドの出力や node_modules が勝手に入らないのは、この仕組みのおかげです。

逆の落とし穴もここにあります。一度コミットしてしまったファイルは追跡対象になるため、あとで .gitignore に名前を書いても除外されません。除外の設定が効くのは追跡されていないファイルに対してだけで、この順番を知らないと「無視の設定を書いたのに毎回差分に出る」という状態が続きます。

手を動かす順番を1本の線にする

順番を1本にしておくと、迷う場面が減ります。最初にリポジトリを用意する段階では、手元で始めるなら git init、既にあるものを取ってくるなら git clone です。ここから先は同じ形を繰り返します。

git status
git add README.md
git commit -m "READMEに導入手順を書いた"
git log --oneline

ステージに載せるコマンドには、ファイルかディレクトリのパスを渡します。ディレクトリを指定した場合は、その配下のファイルを再帰的に追加します。範囲を広く取りたくなる場面は多いのですが、まとめて追加するほど、あとで「このコミットに何が入っているのか」が説明できなくなります。1つの意味の変更を1つのコミットにする、という方針を先に決めておくほうが後で効きます。

コミットの前に中身を確かめたいときは差分を見るコマンドを打ちます。引数なしで打つと作業ツリーとステージの差、--staged を付けるとステージとコミットの差が出ます。この2つが別物だという点が最初の関門で、ステージに載せた後に引数なしで打って何も出ないのは異常ではありません。載せた分は --staged 側に移っています。

記録した履歴を見るのは git log です。--oneline で1コミット1行、--graph を足すとブランチの分岐が線で出ます。履歴を眺める習慣があると、コミットメッセージを雑に書かなくなります。

最初の1回だけ必要な設定を先に済ませる

コマンドを覚える前に、1回だけ済ませておく設定があります。コミットには記録した人の名前とメールアドレスが埋め込まれるため、これが空だとコミットの段階で止まります。手元の機械で一度 git config --global user.name と git config --global user.email を設定しておけば、以後どのリポジトリでも聞かれません。仕事用と個人用でアドレスを分けたい場合は、リポジトリごとに --global を外して上書きできます。

もう1つ、最初に決めておくと後で混乱しないのが最初のブランチの名前です。公式のマニュアルは、リポジトリを作ったときの既定の名前について、現時点では master であり、Git 3.0 の公開時に main へ変わると書いています。名前は init.defaultBranch の設定で変えられるほか、作るときに git init -b で指定もできます。手元は master、共有先は main という食い違いは、この設定を先に合わせておけば起きません。

• 名前とアドレス: git config --global user.name と git config --global user.email
• 最初のブランチ名: init.defaultBranch、または git init -b
• 除外するファイル: リポジトリの一番上に .gitignore を置く

この3つは、どれも後から変えられます。ただし除外の設定だけは順番が効くため、最初のコミットの前に書いておくのが一番手数が少なくなります。

リモートとのやりとりは2つだけで足りる

1人で使っている間はリモートが要りませんが、別の機械と共有する段になると、送るコマンドと取ってくるコマンドが入ってきます。この2つは、追跡設定があるかどうかで書き方が変わります。

ローカルのブランチとリモートのブランチは、名前が同じだから繋がるわけではありません。branch.<名前>.remote と branch.<名前>.merge という2つの設定が書かれていて初めて対応します。リモートのブランチから枝を切ったときは既定でこの設定が入るため、引数なしで通ります。手元で新しく作ったブランチは設定が空なので、最初の1回だけ -u origin ブランチ名 のように送り先を書きます。

取ってくる側にも選択肢があります。git fetch はリモートの状態を手元に持ってくるだけで、作業ツリーを書き換えません。git pull は fetch のあとに統合まで進めます。他の人が動かしているリポジトリでは、先に fetch して git log --oneline HEAD..origin/main で差分を見てから統合する、という順番が安全です。

取り消しの手順を、進める手順と一緒に覚える

初心者向けの説明は進める側に偏りがちで、戻し方が後回しになります。実際に手が止まるのは戻す場面なので、ここを先に押さえたほうがメリットが大きいです。

ステージに載せたものを下ろすだけなら git restore --staged ファイル名 です。公式の説明では、--staged を付けたときはHEADから内容を戻し、付けないときはステージから戻す、と役割が分かれています。つまり作業ツリーの編集を捨てたいときは git restore ファイル名、ステージだけ取り消したいときは --staged を足す、という使い分けになります。

古い解説には git checkout -- ファイル名 が出てきますが、この書き方には注意が要ります。公式のマニュアルは、パスを指定した git checkout を「パスに一致するファイルの内容を上書きする」動作として説明しています。上書きされた編集はどこにも記録されないため、戻す手段がありません。同じ目的なら git restore のほうが、ファイルを指定しているつもりでブランチを切り替えてしまう事故が起きません。

コミットまで済んでしまったものを扱うときは、git revert と git reset の違いを先に決めます。git revert は打ち消すコミットを新しく積むので履歴が残り、共有済みの履歴でも使えます。git reset は履歴そのものを動かすため、まだ誰にも渡していない手元のコミットに限って使います。

道具は画面とコマンドの両方を持っておく

Gitの操作をコマンドで覚える価値は、どの画面でも同じ手が通るところにあります。一方で、差分を読む作業や、どのファイルをステージするか選ぶ作業は、一覧が見える画面のほうが速いのも事実です。公式サイトもコマンドラインとGUIクライアントの両方を並べて紹介しています。

現実的な落としどころは、記録の操作をコマンドで打ち、確認の操作を画面で行う形です。ここで時間を食うのが、フォルダの窓、ターミナルの窓、エディタの窓を行き来する移動そのものです。ファイルを選び、状態を確かめ、差分を読み、また別の窓に戻る。1回あたりは数秒でも、1日に何十回も繰り返せば無視できない量になります。

フォルダとターミナルとAIが同じ窓にある形にすると、この移動がなくなります。ファイル管理アプリでできることの範囲はできることに整理してあり、既に使っているファイル管理の道具と何が違うのかは他のファイル管理との比較にまとめてあります。

手が止まる場所を、窓の数で数える

Gitの基本操作でつまずく場面を並べると、コマンドを知らないから止まっているケースは意外に少ないという傾向が見えます。多いのは次の3つです。

• いまどのディレクトリで打っているのか分からないまま操作している
• 状態を確かめるコマンドの出力と、フォルダの中身が頭の中で繋がらない
• 差分を読むために別のアプリを開いた結果、元の作業に戻れない

3つとも、コマンドの知識では解けません。解けるのは、ファイルの位置とコマンドの結果が同じ画面に並んでいるかどうかです。ここを整えると、覚えるコマンドの数は増えないまま、手が止まる回数が減ります。

料金の考え方や試せる範囲は料金に、導入前に多い質問はよくある質問に置いてあります。移動中にiPhoneやiPadから続きを見る使い方はiPhone・iPadから続きをを参照してください。

覚える順番は、状態を読む、記録する、戻す、共有する、の4段です。この順で身につけると、次に何を調べればよいかを自分で決められるようになります。