独学でプログラミングを始めると、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を取得しましょう。
なお、GitHubでSSH接続の設定を行いたい方は次のページも参考にしてください。
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-branchcherry-pick
他のブランチにある特定のコミットだけを取り込みます。
git cherry-pick [commitID]複数のコミットの取り込みや、連続したコミットの範囲指定による取り込みもできます。
別記事で詳しく解説しました。
» 参考：【すぐ分かる】チェリーピック（git cherry-pick）の使い方
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 と覚えておくと安全です。
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_globalGit トラブルシューティング（よくあるエラーまとめ）
よくあるつまずきポイントをまとめておきます。
push rejected（non-fast-forward）
リモートが進んでいるので、一度 git pull してから push します。
.gitignore が効かない
すでに履歴に入っているパターンです。
git rm --cached が必要です。
Detached HEAD になった
git switch <branch> で戻れます。
変更したのに反映されない
add / commit / push のどこかが抜けているパターンです。
コメント