「GitHub 触れます」と言いながら、実際には GUI でボタンを押しているだけ、という状態は珍しくありません。でも実務で詰まりやすいのは、むしろその先です。今どんな変更があるのか、何を commit しようとしているのか、pull して安全か、push して大丈夫か。そこは CUI で読めた方が強いです。
この記事の要点
- Git は履歴管理の仕組みで、GitHub はその Git を共有・運用するためのサービスです。
- CUI で最低限読むべきなのは
git statusとgit diffです。 statusやdiffのように雑に省略するより、git status、git diffのように正しい文字列で把握した方が事故が減ります。- 基本の流れは「確認 → 差分確認 → add → commit → pull → push」です。
GitHub とは何か。まず Git と分けて考える
GitHub は Git そのものではありません。Git は変更履歴を記録して戻せるようにする仕組みで、GitHub はそのリポジトリをリモートで共有したり、レビューしたり、issue を管理したりするための場所です。
つまり、「GitHub を使っている」だけでは、必ずしも「Git を理解している」ことにはなりません。実際に変更を読むのは、手元の Git です。
なぜ CUI 管理が必要なのか
GUI は速いですし、普段使いには便利です。ただ、ボタンに抽象化されている分だけ、何が起きているのかが見えにくいことがあります。CUI なら、今の状態と差分がそのまま文字で出ます。
特に競合しそうな時、意図しないファイルが混ざった時、コミット前に不安な時は、結局は CUI の確認に戻れる方が安定します。
文字列が変なら、まずコマンド名を正す
よくある崩れ方は、status、diff、add、commit、pull、push だけが頭に残っている状態です。でも実際に打つべきなのは Git のコマンド なので、正しくは次です。
git statusgit diffgit addgit commitgit pullgit push
省略して覚えると順番も意味もぼやけます。文字列をちゃんと直すだけでも、頭の中の整理はかなり進みます。
最小フローはこれで十分
まずは次の流れだけ読めれば、普段の更新はかなり安定します。
git status
git diff
git add path/to/file
git commit -m "Describe the change"
git pull --rebase origin main
git push origin main常にこの形で固定しろという話ではありません。ただ、順番の軸があるだけで、GUI しか触れない状態よりずっと強いです。
まず見るのは git status
git status は「今どうなっているか」を読むための入口です。変更済みファイル、ステージ済みファイル、未追跡ファイル、現在のブランチなど、最初に必要な情報がここに出ます。
何か起きた時にいきなり git add . へ行くより、先に status を見る癖の方が安全です。
中身を見るのが git diff
git diff を見ずに commit すると、何を履歴に残したのか自分でも曖昧になりやすいです。CUI 管理の強さは、この差分を文章のように読めるところにあります。
行単位で何が消えて、何が増えたのかが見えるので、「この修正だけのつもりだったのに別の変更が混ざっている」といった事故に気づきやすくなります。
git add と git commit は役割が違う
git add は commit したい変更を選ぶ操作で、git commit はその時点の変更を履歴として残す操作です。ここが曖昧だと、余計な変更を混ぜたまま commit しやすくなります。
とりあえず全部 add するより、まず何を含めたいのかを言葉で言える状態にしてから add した方が、履歴も読みやすくなります。
git pull と git push は送受信の区別で覚える
git pull はリモートの変更を取り込む側で、git push は自分の変更をリモートへ送る側です。この方向が曖昧だと、今どちらに寄せているのか分からなくなります。
特に共同作業や本番反映前は、pull 前に status と diff を見て、自分の作業ツリーがどうなっているかを確認しておく方が安全です。
GitHub を使うだけでなく、Git を読める状態にしておく
GitHub は便利です。でも、最後に作業を支えるのは Git の状態を読む力です。CUI 管理できていますか、と聞かれた時に、git status と git diff を自然に見に行けるなら、かなり土台はできています。
逆にそこが曖昧なら、まずはコマンド名を正しく覚えて、意味を分けて理解するところからで十分です。派手な操作より、基本の文字列を正しく持っている方が、結局は強いです。
よくある質問
GitHub と Git は同じものですか？
同じではありません。Git は変更履歴を管理する仕組みで、GitHub はその Git リポジトリを共有・運用しやすくするサービスです。
GUI だけで Git を触っていても問題ありませんか？
問題はありませんが、状態確認や差分確認、競合時の理解では CUI の基礎がある方が強いです。最低限 git status と git diff を読めるだけでも事故が減ります。
git pull と git push はどの順番で使えばよいですか？
まずローカル変更を確認し、必要なら commit したうえで git pull で取り込み、最後に git push で自分の変更を送る流れが基本です。