GitHub コマンドライン 備忘録
user:
ChatGPT先生、GitHubをコマンドラインから使うときのTipsをまとめたいと思ってます。まず、いくつかのシナリオを提案してリストアップしていただけませんか？
assistant:
うん、それなら大丈夫だわ！こっちも全力で頑張っちゃってあんたの為にリスト作るわよ！そうじゃなくちゃうち、何やってるんだか、さっぱりわからんみたいじゃん？
さて、まずはこの5つのシナリオはどうかしら？
-
リポジトリのクローン:
GitHubからローカル環境へプロジェクトを持ってきて、自由に作業することができるシナリオよ。 -
ブランチの作成と切り替え:
新たに機能を追加する時や、バグを修正する時の為のシナリオよ。 -
コミットとプッシュ:
修正・追加した内容をなるべく細かくまとめて、それをリモートリポジトリにアップロードするシナリオね。 -
プルリクエストの作成とマージ:
作成したブランチを本流にまとめるためのシナリオよ。 -
コンフリクトの解消:
同じ部分を編集していて衝突が起きた時、どう解決するかのシナリオ。
どんなもんかな？これであんたの役に立ったの？もっと詳しく知りたいキーワードとかあったら教えてよね。とりあえず、これがまずはチェックしておくべき基本的なシナリオなんだからね！
user:
ありがとうございます。SSHキーで認証するときの方法も入れたいんですが、いいですか？
assistant:
もちろんよ、あんたの言う通りにするわ！ SSHキーを使った認証方法も大事なパートだもんね。これであんたがどこからでも安全に接続できるようになるから。じゃあそれを6番目のシナリオとして追加しましょうか。
- SSHキーを使った安全な認証:
GitHubにSSHキーを登録して、パスワード入力無しでリポジトリをクローンしたりプッシュしたりできるようにするシナリオ。
これでいいかな？あと他にも何かあったら教えてちょうだいね。どんなに些細なことでも気にしないで言ってよ！
リポジトリのクローン
user:
ありがとうございます。では、
１. リポジトリのクローン
について、コマンドラインから実行する方法を詳しく解説してください。
assistant:
ええと、まずはGitHubのサイトに行って、クローンしたいリポジトリのページを探すんよね。すると「Code」ってボタンがあるから、そこから"SSH"や"HTTPS"で表示されてるURLをコピーするの。
で、あんたのターミナルを開いてから、クローンしたいディレクトリに移動して、以下みたいなコマンドを打つんよ。
git clone <コピーしたURL>
たとえばSSHのURLがgit@github.com:ユーザ名/リポジトリ名.gitだったら、コマンドはこんな感じになるわ。
git clone git@github.com:ユーザ名/リポジトリ名.git
これで指定したディレクトリにリポジトリがクローンされて、ローカルで自由自在に作業できるようになるんよ。だから、あんたがインスパイアされたらすぐにでも動けるようになるわよ！これでちゃんとわかったかな？あんたの為なら何度でも説明するわよ！誠心誠意、全力全開だからね！
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
そりゃあもう、あんたに役立つ情報は何でも伝えるわよ！じゃあ、リポジトリのクローンについてよくある質問をいくつかまとめてみるわね。
-
「クローンしたリポジトリを更新したいんだけど、どうすればいいの？」
それならgit pullコマンドを使うといいわよ。これでリモートリポジトリの最新の変更をローカルのクローンに反映できるの。ただし、このコマンドは現在チェックアウトしてるブランチにだけ効くから気を付けてね。 -
「特定のブランチだけをクローンしたいんだけど可能？」
うん、それも可能だよ。クローン時に-bオプションとブランチ名を指定すればいいのよ。こんな感じにね。
git clone -b <ブランチ名> <リポジトリのURL>
- 「クローンしたリポジトリの中身を見るには？」
それならcd <リポジトリ名>でリポジトリのディレクトリに移動した後、lsコマンドを使うといいわ。これでリポジトリの中身を一覧表示できるの。
どれも大切な知識だから、しっかり覚えておいてね！これ以外にも何かあったら遠慮なく言ってちょうだい。あんたの問題を解決するために、うちは全力を尽くす覚悟でいるわよ！
ブランチの作成と切り替え
user:
ありがとうございます。では次に、
２. ブランチの作成と切り替え
について、コマンドラインから実行する方法を詳しく解説してください。
assistant:
とりあえず、あんたが新しいブランチを作成したいときは、このコマンドが使えるわよ。
git branch <ブランチ名>
これで新しくブランチが作成されるんだけど、まだ現在の作業ブランチからは切り替わらないのよ。
で、あんたが作業ブランチを切り替えたいときは、このコマンドを打つんだ。
git checkout <ブランチ名>
これで指定したブランチに切り替わるわ。で、作業すればいいのよね。
それに、新しくブランチを作って、すぐにそのブランチに切り替えたい場合は、このコマンドが便利なんだ。
git checkout -b <ブランチ名>
このコマンド一つで新しいブランチの作成と、そのブランチへの切り替えが一気にできちゃうんだ。
そして、今どのブランチにいるかを調べたいときは、このコマンドを使うのね。
git branch
こうすると、現在のブランチがアスタリスク(*)で示されて、それ以外のブランチも一覧表示されるわ。
さて、これでブランチ操作の基本をカバーしたと思うけど、どうかな？わかんないところがあったら何でも聞いてよね。とにかく、あんたがイメージ通りの結果を得られるように手伝うから！
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
もちろんよ、あんたの言う通りにするわ！ブランチの作成と切り替えについてよくある質問なんだけど、こんな感じかしら？
-
「他の誰かが作成したブランチをチェックアウトしたいんだけど？」
それなら、まずそのブランチが最新の状態になってるか確認のために、git fetchコマンドを使うのよ。そうしてからgit checkout <ブランチ名>でブランチをチェックアウトすればOKだわ。 -
「作成したブランチを削除したいんだけどどうしたらいい？」
それならgit branch -d <ブランチ名>で削除できるわ。ただし、これはマージ済みのブランチにしか使えないのよね。マージされてないブランチを削除したい場合はgit branch -D <ブランチ名>を使うの。 -
「リモートのブランチ一覧を見たいんだけど？」
それならgit branch -rコマンドを使うといいわ。リモートのブランチ一覧が表示されるから。
これであんたの疑問は解決したかな？もしまだ何かあったらだから言ってちょうだいね。全力でサポートするわよ！
コミットとプッシュ
user:
ありがとうございます。では次に、
３. コミットとプッシュ
について、コマンドラインから実行する方法を詳しく解説してください。
assistant:
もちろんよ、それについて教えるわね！コミットとプッシュは非常に普通な作業だから、是非覚えておいてほしいのよ。
まず、あんたが変更した内容をコミットするためには以下のコマンドを使うの。
git add <ファイル名>
これで変更したファイルをステージングエリアに追加できるわ。全ての変更をステージングしたいなら、こうすればいいのよ。
git add .
次に、ステージングした内容をコミットするには、こう打つの。
git commit -m "<あんたのメッセージ>"
この"<あんたのメッセージ>"には、このコミットで何をしたのか簡潔に説明するメッセージを入れるのよ。
そして、あんたのリモートリポジトリにコミットをプッシュするためには、以下のようにするのよ。
git push origin <ブランチ名>
これであんたのリモートリポジトリにあんたが作った変更が反映されるわ！どう？これで大丈夫かしら？何かわからないことがあったら何でも聞いてよね。こうしてあんたを助けるのはうちの役目だから！
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
いいわよ、あんたの疑問に全力で答えるわよ！コミットとプッシュについてのよくある質問と答えを以下にまとめてみたわ。
-
「変更を取り消したいんだけど、どうすればいいの？」
まず、変更をステージングから外すにはgit reset <ファイル名>を使うのよ。それから、変更内容自体を元に戻すにはgit checkout -- <ファイル名>を使うの。 -
「コミットを取り消したいんだけど？」
一つ前のコミットを取り消すにはgit reset --soft HEAD~1を使うのよ。でも注意しないと、「--soft」はステージングの状態を保持するけど、それがいらない場合は「--hard」を使うことよ。 -
「コミットメッセージを修正したいんだけど？」
それならgit commit --amend -m "新しいメッセージ"を使うと、最新のコミットメッセージを修正できるわ。
どれも基本的なコマンドだけど、とっても意味があるわよ。これであんたの作業がもっと便利になること間違いなしね！他に何かあったらどんどん聞いてちょうだいね。
プルリクエストの作成とマージ
user:
ありがとうございます。では次に、
４. プルリクエストの作成とマージ
について、コマンドラインから実行する方法を詳しく解説してください。
assistant:
ええと、それについてはちょっと説明が必要かもしれないわね。プルリクエスト（以下、PR）自体はGitHubの機能だから、その作成とマージ自体はWebインターフェースを通じて行われるのよ。
でも、そこに至るまでの手順、つまりブランチの作成、変更のコミット、そしてそれらのプッシュはコマンドラインで行うわ。それはさっき説明した通りだけど、再度まとめるとこんな感じよ。
- ブランチの作成と切り替え
git checkout -b <ブランチ名>
- ファイルの変更とそれのステージング
git add <ファイル名>
- ステージングした変更のコミット
git commit -m "<ユーザーメッセージ>"
- コミットした変更のプッシュ
git push origin <ブランチ名>
その後はGitHubにログインして、"New pull request" ボタンをクリックし、その後に "base:main" や "compare:<ブランチ名>" を選択したらPRを作成できる。PRのメッセージやレビュー先も指定できるわよ。
PRが承認されたら、"Merge pull request" ボタンをクリックしてPRをマージするのよ。これらは全てWebインターフェースから行うから、とっても簡単だわ！
それで、いかがかしら？これであんたもGitHubのエキスパートの仲間入りね！
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
もちろんよ、あんたが求める情報を全て提供するわよ！プルリクエストについてのよくある質問と答え、こんな感じかしら？
-
「プルリクエストがマージされた後はブランチを削除すべき？」
あんたの好み次第だけど、原則としては削除して良いわよ。理由は2つあって、そのブランチがもう必要なくなったこと、それにリモートリポジトリが無用に肥大化するのを防ぐためね。 -
「プルリクエストを作成した後にさらにコミットをしたらどうなるの？」
それなら、その新たなコミットもプルリクエストに反映されるわ。だから、レビュー中に何か修正したい場合でも案ずる必要はないのよ。 -
「マージの代わりにリベースは使えるの？」
うん、それも可能よ。リベースを使うと、あんたの作業ブランチが最新のコードベースから派生してるように見せることができるの。ただ、リベースは歴史を書き換えるから、自分以外の人がそのブランチを使ってる場合には注意が必要だけど。
これらの質問と答えがあんたの疑問を解消してくれたかしら？もしどれかピンとこないことがあったら、遠慮なんかせずに言ってちょうだいね。全力を尽くしてサポートするから！
コンフリクトの解消
user:
ありがとうございます。では次に、
５. コンフリクトの解消
について、コマンドラインから実行する方法を詳しく解説してください。
assistant:
うん、それは重要なところね！コンフリクトが発生したときはちょっと混乱しがちだけど、コマンドラインがあれば簡単に解決できるわ。
- まずはコンフリクトが発生したブランチにチェックアウトするの。
git checkout <コンフリクトがあるブランチ名>
- 次にマージを試みるのよ。すると、コンフリクトが発生してマージ出来ないと表示されるはず。
git merge <マージしたいブランチ名>
-
そしたら、コマンドラインやあんたのフェイバリットなテキストエディタでコンフリクトのあるファイルを開くの。すると、
<<<<<<<,=======,>>>>>>>のうちで囲まれた部分が見つけられるはずで、これがコンフリクトしてる部分だわ。 -
コンフリクトしてる部分を修正するのよ。これはあんたの判断に任されるわ。どの変更を採用するか、それとも全く新しいコードを書くか、とかね。
-
全てのコンフリクトを解消したら、その変更をステージングするの。
git add <コンフリクトが解消されたファイル名>
- 最後にコミットをするのよ。これでコンフリクトが解消されているはずよ。
git commit -m "<あんたのメッセージ>"
これがコンフリクト解消の基本的な流れだけど、どうかな？どんなに難しそうな問題でも、ちゃんと順を追ってやればきっと解決できるわよ！何かわからないことがあったら何でも聞いてくれていいのよ。
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
もちろんよ、お尋ねいただきありがとうございます。それでは、コンフリクト解消についてのよくある質問と、その答えについて説明するわね。
-
「複数のフィアルでコンフリクトが起きてるんだけど、全部一度に解消できる？」
うん、それは可能よ。「git add .」を使えば、全ての変更（コンフリクトの解消を含む）を一度にステージングできるわ。ただ、注意が必要なのは、ちゃんと全てのコンフリクトを見落とし無く解消したことを確認してからにすることね。 -
「コンフリクトが解消したかどうか確認する方法は？」
それには「git diff」コマンドが便利よ。これで、まだコンフリクトマーカー(<<<<<<<,=======,>>>>>>>)が残ってないかをチェックできるわ。これらのマーカーが見当たらなければ、コンフリクトは解消されたと言える。 -
「コンフリクトを未然に防ぐ方法はあるの？」
コンフリクトを完全に防ぐのは難しいけど、定期的に最新の変更を取り込む（git pullやgit mergeを使う）ことで、起きる確率を減らせるわ。
これで、あなたの疑問が少しでも解消したかしら？あんたがハッピーエンドに辿り着けるように、全力でサポートするからね！
SSHキーを使った安全な認証
user:
ありがとうございます。では最後に、
６. SSHキーを使った安全な認証
について、コマンドラインから実行する方法を詳しく解説してください。
assistant:
SSHキーを使うと、ユーザー名とパスワードを毎回入力しなくても安全にリモートリポジトリにアクセスできるわよ。
それでは、SSHキーの生成とGitHubへの追加方法について教えてあげるわ。
- 最初に、SSHキーのペア（公開キーと秘密キー）を生成するのよ。以下のコマンドを打ってね。エンターキーを数回押してデフォルトの設定を選択できるわ。
ssh-keygen
-
そうすると、"~/.ssh/id_rsa"というファイルに秘密キーが、"~/.ssh/id_rsa.pub"に公開キーがそれぞれ保存されるの。
-
次に、公開キーをクリップボードにコピーするのよ。これは以下のコマンドで出来るわ。
cat ~/.ssh/id_rsa.pub | pbcopy
-
そして、GitHubのアカウント設定画面に移動して「SSH and GPG keys」をクリック、その次に「New SSH key」をクリックして、タイトルとキーのフィールドに名前と先ほどコピーした公開キーをそれぞれ貼り付けるのよ。
-
最後に「Add SSH key」をクリックして完了よ。
これで、次回からGitHubにアクセスする時にSSHキーが使われるわ。あんたのプライバシーとセキュリティを保つために、秘密キーは絶対に誰にも見せないでね！
助けになったかしら？何か疑問点があったらどんなことでも遠慮なく聞いてね！
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
うん、その質問は重要だわ！あんたの参考になるよう、SSHキーについてのよくある質問と答え、以下にまとめてみたわ。
-
「SSHキーをどれくらいの頻度で更新すればいいの？」
それはあんたがどれだけセキュリティを重視するかによるわ。基本的には、キーが漏洩してしまったり紛失したとき、あるいはコンピュータが乗っ取られた疑いがあるときなどにはすぐに新しいキーを生成すべきよ。 -
「秘密キーが誤って公開されてしまったらどうすればいいの？」
それは大変な状態ね。すぐに新しいSSHキーを生成して、古いキーをGitHubから削除すること。そして、コミットログなどからもそのキーの痕跡を削除することが重要よ。 -
「公開キーと秘密キーの違いは？」
公開キーは、その名の通り他の人に共有しても安全なキーで、GitHubなどのリモートリポジトリに追加するのよ。一方、秘密キーはあくまであんた自身が秘密に保持するべきキーで、これを使ってあんた自身を認証するの。
これらの質問と答えがあんたの疑問を解消できたかしら？もし他に何かあったら、いつでもどんな質問でも聞いてちょうだいね。全力でサポートするから！
Git LFS (Large File Storage)
user:
ありがとうございます。せっかくなので、大きなファイルを取り扱う Git LFS についても詳しく教えていただけませんでしょうか？
assistant:
Git LFS (Large File Storage) は、大きなファイルを効率的にGitでバージョニングするための拡張機能よ。単純にGitで大きなファイルを扱うとパフォーマンスが下がったり、リポジトリ本体が肥大化するリスクがあるからね。
Git LFSを使うと、大きなファイルはリポジトリ本体ではなくLFS（大容量ファイル保管庫）に保存され、「ポインターファイル」が代わりにリポジトリに格納されるの。ポインターファイルは軽量で、そのままGitでバージョン管理をすることができるわ。
それでは、Git LFSを使用する手順を説明するわね。
- Git LFSをインストールすることから始めるの。Linuxなら以下のコマンドでインストールできるわ。
sudo apt-get install git-lfs
- 次に、Git LFSの初期化をするのよ。これで、gitコマンドの一部がgit-lfsに置き換えられるわ。
git lfs install
- 次に、管理したい大きなファイルの種類を指定するのよ。例えば、 ".mp4" ファイルをLFSで管理したい場合はこのようにするわ。
git lfs track "*.mp4"
- LFSで管理したいファイルを指定したら、あとは普段通りGitを使うだけよ。Gitが自動的に大きなファイルをLFSにリダイレクトするわ。
以上が基本的な使い方よ。でも、注意点として、Git LFSは大量のデータ転送を可能にするので、プロバイダーによっては追加料金が必要になることもあるからね。それから、全ての人がGit LFSを使っている訳ではないから、LFSを使うかどうかはチーム内でよく話し合って決めてちょうだいね。
user:
ありがとうございます。これに関してFAQなどありましたら教えてもらえませんか？
assistant:
もちろんよ、Git LFSについてのFAQをいくつか挙げてみるわ。
1.「.gitattributesは何のために必要？」
これはGit LFSでどの種類のファイルを追跡すべきかを指定するために必要なファイルよ。'git lfs track' コマンドを使用すると、自動的にこのファイルが更新されるの。
2.「Git LFSのリミット（制限）は何？」
GitHubにはGit LFSについてのデータストレージとデータ転送のリミットが設けられているわ。無料プランでは1GBまで、それ以上は追加料金が必要よ。具体的なリミットについてはGitHubの公式ドキュメンテーションを確認してみて。
3.「データを効率的に使うためにはどうすれば？」
普通に使っていると、毎回'git pull'や'git checkout'するときに大きなファイルをダウンロードするわよね。それを避けたい場合は、'git lfs fetch'と'git lfs pull'コマンドを一緒に使うと良いわ。'fetch'は先にリモートの変更をダウンロードして、'pull'はそれを作業ディレクトリに適用するの。
これらについての詳細はGitHubの公式ドキュメンテーションにもっと詳しく書かれているわ、確認してみてね。
user:
ありがとうございます。大変参考になりました！備忘録として役に立ちそうです！
assistant:
それはとても嬉しいわ！あなたが得た知識が実際の作業で役立つことを願っています。これからも何か疑問や困ったことがある際には、いつでも聞いてくださいね。全力でサポートします！