プロが教える、業界最前線のノウハウ【Coloso】

困ってた自分に届けたい話

「あのとき、コマンド知っていれば…！」

初めてチーム開発に参加したとき、GitHubの操作に自信がなくて、GUIでぽちぽちと安全そうなボタンを押すばかり。正直、黒い画面（CLI）ってプロっぽくてかっこいいけど、自分にはまだ早いと思ってました。

でも、GUIのツールがアップデートされたり、チームごとに使うツールが違ったりすると、
「え、どこ押せばよかったっけ？」と、毎回迷子に。

そのうち、

• 同じブランチ名で強引にプッシュしてコンフリクトの嵐
• コミットメッセージがバラバラで履歴がぐちゃぐちゃ
• リモートの変更を取り込まないまま作業を進めて大混乱

という、地味だけど痛いトラブルを何度も経験。

「コマンドで操作できていれば、もっと早く正しく対応できたのに…！」と何度も後悔しました。

てんハロ運営者

この記事は、同じように困っていた方への備忘録兼シェアとして書いています。

リポジトリの初期化・クローン

新しく作るとき（自分でゼロから開発を始めるとき）

git init

自分だけのポートフォリオサイトを作るときや、チームにまだ共有しない段階の個人開発を始めるときに、すでに作成したフォルダの中でこのコマンドを打つことで、そのフォルダが「Gitで履歴管理できる状態」になります。その後、GitHubに新しく作ったリモートリポジトリと紐づけるためには、次のようにします。

git remote add origin https://github.com/ユーザー名/リポジトリ名.git

これで、ローカルとGitHubの接続が完了します。

他の人のリポジトリやチームのリポジトリを使いたいとき

git clone https://github.com/チーム/リポジトリ名.git

すでにあるプロジェクトを自分のPCに持ってきたいときに使います。GitHubの「Code」ボタンからURLをコピーして、ターミナルでこのコマンドを実行すると、フォルダごと全部ダウンロードされます。履歴も含まれるので、過去の変更もすべて確認できます。

コミットと履歴管理

ファイルを追加・変更したら履歴に残すとき

git add .
git commit -m "ヘッダーのデザインを調整"

コード修正したあと、そのまま次の作業に進むのではなく、まず変更を一つの「区切り」として記録しておきたいときに使います。
git add . は、全ての変更されたファイルを「記録準備OK」の状態にするコマンドです。
その後、git commit -m "..." でメッセージをつけて保存します。
ここでのメッセージは「何を」「なぜ」変更したのかをチームがわかるように簡潔に書きましょう。

直前のコミットを修正したいとき

git commit --amend

「コミットしたあとにファイルの入れ忘れに気づいた」「メッセージに誤字があった」「やっぱりちょっと修正したい」——そんなときに使えるのが git commit --amend です。

このコマンドを実行すると、直前のコミットを上書きする形で修正できます。たとえば、ファイルを追加し忘れていたなら、そのファイルを git add でステージングしてから git commit --amend を実行すれば、1つのまとまったコミットにすることができます。

なお、すでにGitHubにpushしているコミットをamendすると履歴が変わるため注意が必要です（その場合は --force 付きで再pushが必要になります）。

ローカル作業中に「コミットやり直したい」と思ったら、まず git commit --amend を思い出してみてください

過去の履歴をパッと確認したいとき

git log --oneline --graph --decorate

誰がいつどんな変更をしたかを見たいときに使います。
長い履歴をだらだらと読むのではなく、1行ずつコンパクトに見られるので視認性がとても良いです。
--graph をつけることで、どのブランチがどこから分かれて、どこで合流したかもわかりやすくなります。

ブランチ操作

作業用の新しいブランチを作って、すぐに移動したいとき

git switch -c 新しいブランチ名

最近のGitでは、ブランチの切り替えや作成は git checkout よりも git switch を使うのが主流になっています。たとえば新しいブランチを作ってすぐにそのブランチに移動したいときには、git switch -c feature/新しいブランチ名 のように書くと、一発でローカルブランチ作成・切り替えが完了します。
すでに作られているブランチに移動したいときは、git switch ブランチ名 だけでOKです。

今のブランチを確認したいとき・他のブランチを見たいとき

git branch

今までに作成されたローカルブランチが一覧で表示されます。今自分がいるブランチには * がついています。作業の前に「今どこにいるか」を確認する習慣をつけるとミスが減ります。

てんハロ運営者

異なるローカルブランチで作業していたことがあり、大変な目に何度もあっている主です。この習慣は大切です… !

作業が終わったブランチを削除したいとき

git branch -d feature/完了したブランチ

不要になったブランチはこまめに消すことで、ローカルがスッキリします。
まだマージしていないのに間違って消そうとすると警告が出ますが、どうしても削除したい場合は -D を使って強制削除もできます。

リモートリポジトリ操作

自分の作業をGitHubにアップしたいとき

git push origin feature/新機能名

作業した内容をチームに共有したいときには、このコマンドでGitHubにアップします。origin はGitHub側のリポジトリ名を意味し、その後に続くのが自分のブランチ名です。もし初めてのプッシュで「上手くリンクできていない」場合は、次のように書くことで自動的に紐づけされます。

git push -u origin feature/新機能名

こうしておけば、次回以降は git push だけでOKになります。

他の人の変更を自分の作業に反映させたいとき

git pull --rebase

GitHub上で別の人が更新していた場合、自分のローカルを最新にしてから作業を再開したいときに使います。--rebase をつけることで、マージコミットを発生させずに履歴をキレイな状態に保てます。

マージ・コンフリクト解消

他のブランチの内容を今のブランチに統合したいとき

git merge ブランチ名

たとえば、現在作業している feature/login-form ブランチに、チームがまとめているメインの開発ブランチ（例：develop や main）の最新変更を取り込みたいときに使います。

この「ブランチ名」の部分には、「取り込みたい変更がある側のブランチ名」を指定します。よくある例としては develop や main ですが、会社やプロジェクトによっては staging や release など別の名前を使っていることもあります。

コンフリクトが起きたとき

ファイルの中に <<<<<<< や ======= が現れたら、それがコンフリクトです。
自分の変更と他の人の変更がぶつかってしまった状態なので、エディタで手動で「どちらを残すか」「どう融合するか」を判断します。修正したら、次のコマンドでコンフリクトが解消されたことをGitに伝えます。

git add コンフリクト解消済みファイル
git commit

トラブルシュート

直前のコミットとの差分を見たいとき

git diff HEAD~1 HEAD

「この前のコミットから何を変えたっけ？」という場面で使います。ファイルを開かなくても、ターミナル上で変更点が確認できます。

昔のコミットに戻したいとき（でも履歴は壊したくない）

git revert <コミットID>

「やっぱりこの機能、いらなかったな…」というときに使います。revert を使えば、「そのコミットを取り消すための新しいコミット」を作ってくれるので、履歴はきれいなまま残ります。履歴を壊す reset より安全です。

作業中の変更を一時的に退避したいとき

git stash

今まさにファイルを編集している途中に「緊急で別ブランチに切り替えて修正お願い！」という指示が来たとします。でもまだコミットもしていないし、今の作業内容は残しておきたい…。そんなときに便利なのがこの git stash コマンドです。

これを実行すると、作業中の変更内容を一時的に「しまっておく」ことができます。ブランチを切り替えたあと、元に戻ってから git stash pop を使えば、さっきまでの変更内容がちゃんと復元されます。

てんハロ運営者

おつかれさまでした！

The post 【初心者向け】現場で役立つGitHubコマンド厳選まとめ｜GUIから卒業したい初心者へ！ first appeared on てんハロ｜未経験エンジニアのIT学習ログ.

てんハロ運営者

バグヲ

どれを使えばいいんだろう〜

てんハロ運営者

こんなあなたにピッタリな記事👇

• GitHubを使い始めたばかり
• git clone に3種類あるのが気になっている
• どれを使えばいいか迷っている

がまぁまぁわかります！

未経験からエンジニア転職を目指すなら
👉 テックゲート転職 をチェック！

Drizzleとは？TypeScriptで型安全にSQL・マイグレーションを管理する方法

Drizzle ORMを使って、TypeScriptで型安全にSQLやマイグレーションを管理する方法をわかりやすく解説。初期設定からスキーマ定義、リレーション設定まで丁寧に紹介！

it-bokenki.com

Gitのクローンには3種類ある

GitHubでリポジトリを自分のPCにクローン（コピー）するため、「Code」ボタンを押すと次の3つの接続方法が表示されます。

📌 例えるなら…

• HTTPS：玄関で名前とパスワードを言わないと入れない（毎回認証が必要）
• SSH：合鍵を持っていればそのまま入れる（1回設定すれば楽）
• GitHub CLI：スマートスピーカー付きの玄関。音声コマンドだけで開け閉めできる（コマンドひとつでPRやIssueの操作も完了）

HTTPSの特徴

git clone https://github.com/ユーザー名/リポジトリ.git

🔓️ 特徴

認証が手軽で誰でも使えるが、push時にtoken入力（認証）が必要
※保存済みなら省略可

✔ 使い方

① GitHubでHTTPSのURLをコピーして貼り付け

② パスワードを求められたら、ユーザー名・トークンを貼り付け

git clone https://github.com/ユーザー名/リポジトリ.git

＞ Username for 'https://github.com': ユーザー名
＞ Password for 'https://github.com': tokenの内容

push時に認証を求められないパターン

🔎 パターン1：すでに SSH 接続に切り替わっている

git remote -v を実行して、下記が表示されたら既にSSH接続を使っているという意味です。
なので git push しても token やパスワードを聞かれないのが正しい挙動です。

git remote -v

＞ origin  git@github.com:ユーザー名/リポジトリ.git (fetch)
＞ origin  git@github.com:ユーザー名/リポジトリ.git (push)

🔎 パターン2：HTTPSだけど、token を保存済み

もし以前に HTTPS で push したときに token を保存していたら、Macの「キーチェーン」などに保存されていて、聞かれないこともあります。

SSHの特徴

git clone git@github.com:ユーザー名/リポジトリ.git

🔓️ 特徴

• 初回のみ、SSH鍵を作成してGitHubに登録
• pushもpullも認証無しでスムーズ
• CI/CDや自動化との相性も高い

✔ 使い方

① SSH鍵（鍵ペア）を作る

ssh-keygen -t ed25519 -C "メールアドレス"

どこの階層（ディレクトリ）でも実行してOK
~/.ssh/id_ed25519（秘密鍵）と ~/.ssh/id_ed25519.pub（公開鍵）が生成されます。

② 公開鍵をGitHubに登録

cat ~/.ssh/id_ed25519.pub

1. 上記のコマンドで、公開鍵の中身を確認してコピー
2. GitHubにログイン
3. 右上のアイコンをクリック → Settings（設定）
4. 左メニューから SSH and GPG keys を選択
5. [New SSH key] ボタンをクリック
6. cat コマンドで表示された公開鍵を貼り付けて保存

GitHub CLIの特徴

gh repo clone ユーザー名/リポジトリ

🔓️ 特徴

• GitHub公式CLIツール
• PR作成やIssue管理もコマンドだけでOK
• SSHとHTTPSの接続設定も対話形式で簡単に切り替えられる

✔ 使い方

公式手順はこちらをご確認ください：https://cli.github.com/

結局どれを使えばいい？

トークン保存済みHTTPSとSSHの違いってあるの？

たしかに、トークンを保存していれば
git push 時に毎回パスワードを入力する必要はなく、操作感は SSH と似ています。

でも、それでも SSH を使うべき理由があります。

HTTPSよりSSHを選ぶメリット

結論

見た目は似ていても、安定性・自動化・セキュリティの面でSSHの方が圧倒的におすすめです。
特に、チーム開発やCI/CDの導入が視野にあるなら、最初からSSHに慣れておくのがベストです。

てんハロ運営者

おつかれさまでした！

The post GitHubのHTTPS・SSH・CLIの違いとは？接続方法の選び方をわかりやすく解説！ first appeared on てんハロ｜未経験エンジニアのIT学習ログ.