独学でプログラミングを始めると、Git はとても身につけにくい技術です。
Git はとても便利な反面、処理のフローが複雑で初学者にとって複雑怪奇。
さらに個人開発では Git なしでもどうにかなってしまうので、学習が後回しになってしまいがちです。
ところが、プログラムが大規模になると Git なしでの開発はほぼ不可能になります。
つまり、会社勤めをするなど複数人で開発するなら Git を扱えることは必須になります。
本記事では CUI を用いた Git 操作を紹介していきます。
【基本】CUI を使った Git の基本操作
まずは日常的に使うコマンドからご紹介します。
init
現在のディレクトリを新たに Git 管理下に置きたい場合のコマンドです。
mkdir my_project && cd my_project
git initこのコマンドを実行すると、.gitディレクトリが作成されます。
これにより、現在のディレクトリのファイルやディレクトリが Git によるバージョン管理の対象になるというわけです。
clone
リモートリポジトリをローカルマシンにクローン（コピー）します。
git clone https://github.com/username/repository.gitコピーしたローカルリポジトリには、リポジトリのコミット履歴やブランチの情報も含まれることになります。
リポジトリーのURLは、リポジトリページの「Code」ボタンから確認できます。
HTTPSまたはSSHのタブをクリックして、URLを取得しましょう。
status
リポジトリの現在の状態（変更内容、コミット状況など）を確認します。
git status
# On branch main
# Your branch is up to date with 'origin/main'.
# nothing to commit, working tree cleanadd
作業ディレクトリでの変更をステージング（次のコミットに追加する準備）します。
ファイル全体をステージングするときは以下のようにします。
# ファイル全体を追加する場合
git add .. は「カレントディレクトリ下のすべて」という意味です。
また、特定のファイルだけをステージングする場合には具体的なファイル名を指定します。
# 特定のファイルを追加する場合
git add README.mdつまり、上記の例ではREADME.mdだけがステージングされることになります。
commit
ステージングされた変更をリポジトリにコミットします。
-mオプションをつけると、一行コメントを入れることができます。
# 一行コメントを入れる
git commit -m "Add initial project files"ただし、一般的には「1行目 = タイトル、2行目 = 空白、3行目 = 詳細」といった感じで書きます。そうすると-mだと物足りないので、次のコマンドを実行します。
git commit実行後に vim が立ち上がるので、以下の要領でコメントを入力していきましょう。
iキーを押すEnterキーを押す（Insertモードになる）- コミットメッセージを入力する
ESCキーを押す:wqをタイプするEnterキーを押す
コメントの記載例をいくつか挙げておきます。
修正: ログイン時のエラーチェックが不十分だった問題を解決
ログインフォームでの入力値チェックが不足しており、特定の入力がエラーを引き起こしていました。
- ユーザ名の空文字を許可しないように修正
- パスワードの最小文字数をチェック機能追加: ユーザープロファイルページに画像アップロード機能を実装
ユーザーが自分のプロフィール画像をアップロードできるようにするため、以下の変更を加えました。
- 画像アップロードのための新しいフォームを追加
- サーバーサイドでの画像処理ロジックを実装
- アップロードされた画像のサイズ制限を設定更新: READMEファイルにインストール手順を追記
新しい依存関係ライブラリに対する説明を追加し、ユーザーがプロジェクトをスムーズにセットアップできるようにしました。
- Pythonのバージョン要件を明記
- 実行に必要な外部ツールのリンクを追加push
ローカルのコミットをリモートリポジトリに送信します。
git push origin mainpull
リモートリポジトリの最新の変更をローカルに取り込みます。
git pull origin mainorigin と main の意味は以下の通りです。
origin
リモートリポジトリのデフォルトの名前がoriginです。
Git でリポジトリをクローンすると、リモートリポジトリのデフォルトのショートカットとしてoriginが設定されます。
これにより URL を繰り返し入力する代わりにoriginとするだけでリモートリポジトリにアクセスできるようになります。
main
リポジトリのブランチ名を指します。
Git では複数のブランチが切られることが多いので、pullしたいブランチ名を正確に指定することが必要になります。
branch
ブランチの確認や作成を行います。
# 既存のブランチ一覧を表示する場合
git branch# 新しいブランチを作成する場合
git branch feature-branchcheckout
ブランチの切り替えや、特定のコミットに移動します。
# ブランチを切り替える場合
git checkout feature-branchブランチを新規作成して、新しくできたブランチに切り替える場合は以下のコマンドを使います。
git checkout -b [新しいブランチ名]merge
別のブランチを現在のブランチにマージ（統合）します。
git checkout main
git merge feature-branchrebaseとの使い分けや、実務でのマージ運用ルールは別記事で詳しく解説しました。
cherry-pick
他のブランチにある特定のコミットだけを取り込みます。
git cherry-pick [commitID]複数のコミットの取り込みや、連続したコミットの範囲指定による取り込みもできます。
別記事で詳しく解説しました。
revertとreset
Git を使っていると、「あのコミットを取り消したい」という場面が必ず出てきます。
ここでよく混乱を招くのが、revert と reset の違いです。結論から言うと：
- reset は歴史を書き換える（危険／共有リポジトリでは原則禁止）
- revert は取り消し用の新しいコミットを作る（安全／実務向け）
という関係です。
revert は “巻き戻す” ではなく “打ち消す”
git revert の動きは直感と少し違い、「過去のコミットを削除する」のではなく、
指定したコミットの変更内容を、反対の変更で打ち消すコミットを作る
というものです。
つまり、履歴を壊さないため、チーム開発や本番運用リポジトリでは revert が圧倒的に安全です。
revert の基本コマンド
単一コミットを取り消す場合：
git revert <コミットID>複数コミットを取り消す場合：
git revert <開始コミットID>..<終了コミットID>コミットメッセージ入力をスキップして自動生成させる場合：
git revert --no-edit <コミットID>実務で revert を使うシーン
- 誤って本番にバグを出してしまったとき
→ 該当コミットを revert すれば “安全に元に戻せる” - PR をマージしたら挙動がおかしくなったとき
→ reset は絶対NG（履歴破壊）。revert 一択。 - Aさんのコミットを B さんが取り消したいケース
→ reset は他人の作業を壊すためご法度。revert が正攻法。
つまり、共有リポジトリでは reset より revert を使う場面の方が圧倒的に多い。
revert と reset の使い分け
まとめると以下です。
| コマンド | 履歴 | 安全性 | 使う場所 |
|---|---|---|---|
| reset | 履歴を書き換える | 危険 | 個人作業ブランチのみ |
| revert | 履歴を残す（取り消しコミットを追加） | 安全 | 共有ブランチ・本番系 |
本番ブランチは reset 禁止、迷ったら revert と覚えておくと安全です。
–soft・–mixed・–hardの違いなど、resetの詳細は別記事にまとめました。
log
リポジトリのコミット履歴を表示します。
git log# ログを1行で表示する場合
git log --onelinediff
コミット間やステージングエリアと作業ディレクトリの変更点を比較します。
# ステージングされていない変更を確認する場合
git diff# ステージングされた変更を確認する場合
git diff --stagedケース別コマンドの組み合わせ
ファイルを追加したり更新した場合
git add -A # 全てステージングする
git commit -m "メッセージ" #コミットする
git push origin main # プッシュする最新のリモートリポジトリを取り込む
git pull origin mainHTTPS から SSH に変更したいとき
認証方法を HTTPS から SSH に変更する場合には、以下のコマンドを実行します。
git remote set-url origin <新しいリモートリポジトリのURL>このコマンドが必要な理由は、HTTPS と SSH でリモートリポジトリの URL が変わるためです。
作業が快適になる Git の便利設定
Git はそのままでも使えますが、設定を少し加えるだけでかなり使いやすくなります。
よく使う alias を設定する
git st で status が出るので、作業がだいぶ快適になります。
git config --global alias.st status
git config --global alias.br branch
git config --global alias.co checkout● mac の .DS_Store を無視したい場合
echo .DS_Store >> ~/.gitignore_global
git config --global core.excludesfile ~/.gitignore_global特定のパターンの除外方法や、すでに追跡中のファイルを後から除外する方法は別記事にまとめました。
Git トラブルシューティング（よくあるエラーまとめ）
よくあるつまずきポイントをまとめておきます。
push rejected（non-fast-forward）
リモートが進んでいるので、一度 git pull してから push します。
.gitignore が効かない
すでに履歴に入っているパターンです。
git rm --cached が必要です。
Detached HEAD になった
git switch <branch> で戻れます。
変更したのに反映されない
add / commit / push のどこかが抜けているパターンです。
Git学習ロードマップ
ここまでの基本操作を一通り触ったら、次は以下の順番で深掘りしていくと実務でつまずきにくくなります。
Step 1: 作業を安全に一時退避する
Step 2: 統合方法を使い分ける
Step 3: コミットを安全に取り消す
Step 4: 特定のコミットだけを取り込む・取り消す
Step 5: 管理対象から除外する
逆引きナビ：目的から探す
「〜したい」から該当の記事を探したい場合は、こちらもご利用ください。
- 作業を中断して別のブランチに切り替えたい → git stashの使い方完全ガイド
- ブランチの履歴をきれいに保ちたい・チームでの運用ルールを知りたい → git rebase・mergeの使い分け完全ガイド
- コミットを取り消したい・安全な取り消し方を知りたい → git resetの使い分け完全ガイド
- 特定のコミットだけを別ブランチに持っていきたい → cherry-pickの使い方
- cherry-pickを間違えた・取り消したい → cherry-pickの取り消し方法
- 特定のファイルをGit管理から除外したい → .gitignoreの書き方完全ガイド
まとめ
Gitは独学だと後回しにしがちですが、覚えるコマンドの数自体はそう多くありません。まずはこの記事の基本操作を手を動かして覚え、つまずいたら該当の詳細記事に進む、という流れで十分です。
コメント