初心者のうちに使った主なgitのコマンドなどまとめ
gitの導入方法やコマンド一覧は他にいろんな記事があるのでここでは省略。
開発サイクル中によく使う必要最低限のコマンドだけを詳しく教えてくれ！ということで初めてgitを利用した個人開発でよく使ったコマンドを備忘録としてまとめる。
ちなみに大文字になっているところは人それぞれ置き換える必要があるところ。実際は大文字で書く必要もない。
gitを使用した開発
開発前にまず確認すること
git checkout main
開発用ブランチなどの作成をするとき、現在いるブランチを基準に新しく作成するので、基本はmainを基準にスタート。
複数ブランチ並行しながら開発しているときは特に注意が必要
開発を始めよう
git checkout -b HOGEHOGE
checkoutはブランチの移動。-bはブランチ作成のオプション。
省略しないで書くと、git branch hogehoge+git checkout hogehoge=git checkout -b hogehogeとなる。
git checkout main後にこのコマンドを叩けば、mainブランチが複製されるということ。
とりあえずコードをいじった。次は？
ここからが最初利便性がわからず、理解に時間がかかった1つ目の厄介ポイント。
が、理解が進むほど「よくこんなもん思いついて構築するなぁ…」と感心したので、ちゃんと理解しておきたい。
自作の図。厳密には意味がズレそうな気がするがこれで一旦説明する。
ローカルリポジトリという名前はgithubを使わないなら覚えなくてヨシ。
ワーキングツリーというのは、要はコードエディタでフォルダを開いた状態。
何も頼らない個人開発だとこのワーキングツリーだけでコードをいじっていくことになる。
正直これだけでもなんとかなりはする。けどgit知ると…
2つのレポート用紙でやりたいことが終わった
git add FILENAME
ファイルだとここからややこしくなるので、レポート用紙とする。
そのレポート用紙をインデックスに登録する必要がある。インデックスはクリアファイルとする。
ちなみにステージングエリアとも呼ばれているらしい。使い分け方は知らない。
このコマンドは、更新したレポート用紙をクリアファイルに入れる作業ということになる。
今回クリアファイルに入れるレポート用紙はファイル1と2だけとする。ちなみにファイル3はメモ帳代わりのレポート用紙なのでクリアファイルには入れないでおく。
なんで一旦クリアファイルにまとめる必要ある？という疑問は開発サイクル内ではほとんど関係がない。
理由は最後の方にあるちょっと知っておくと便利なやつを参照されたし。
git add .
1つ1つ更新したレポート用紙の名前調べるのは面倒なんじゃあという人はファイル名を.とすると、更新したレポート用紙だけを一括で入れられる。すごーい。
git add DIR
とディレクトリ名を指定すると、そのディレクトリに入ってるやつだけを一括で入れられる。パスなので更に深いディレクトリも指定可。
レポート用紙をクリアファイルにまとめたら？
git commit -m "MESSAGE"
git commitでクリアファイルをケース？の中へ上に重ねて入れる。つまりgitリポジトリへ記録する。
このケースの中に入ってるレポート用紙を全て合体したものがhogehogeブランチの最新版、ということになる。(同じ名前のレポート用紙が複数ある場合は、上側にある方のクリアファイルに入ってるやつを優先)
このクリアファイル、後で見返す機会があったときどんな更新をしたのかほぼ思い出せないので、-m "MESSAGE"とメッセージをつけて見返しやすくすることができる。何でも書ける。
今回の画像でいうと不具合修正というテプラが貼ってあるところに当たる。テプラがわからない？調べたまえ
ファイル3は今回クリアファイルには入れてなかったので、gitリポジトリとワーキングツリーで比較すると、ファイル3のレポート用紙だけはgitリポジトリにはないよ、という状態になっている。
もしこの後ファイル3も新しいクリアファイルに入れてcommitしたら完全に一致した状態になる。
やりたいことが一区切りするまでは、このadd~commitを繰り返すことになる。
なお画像ではクリアファイルが4つくらい重なっているが、重ねていく表現を出したかっただけなので以降は無視していい。
全てが片付いたら、mainブランチに合体させる
git checkout maingit merge HOGEHOGE
無事完成したhogehogeブランチ。これを大元のmainブランチへ合流させる。
再度書くが、gitコマンドは現在いるブランチを基準にして操作が行われるので、忘れずにmainへ移動する。そしてhogehogeをmainにmergeする。
なんということでしょう。mainがhogehogeを吸収してパーフェクトmainに進化してしまいました。
最初の画像を引きで見てみるとこんな感じ。
幹から枝生やして色々やって幹にくっつけ直す。これを永遠と繰り返していくのがgitの基本。
使い終わったブランチは？
git branch -d HOGEHOGE
使い終わったブランチはもう用済みなんだ。今までありがと。じゃあね。
ちなみに自分自身は消せないので、mainブランチなどに移動してからブランチ名を指定して消すこと。
あれ、ファイル3はどうするの？と思ったあなた。鋭い。
作業途中のレポート用紙が残ってる間はcheckoutで移動が出来ない。ここでは捨てて強制移動してOK。
残したまま移動したいんだけど…という場合はgit stashの方を見ていただきたい。
開発を始めよう
git checkout -b HOGEHOGE
という感じでループしていく。
さて、もしかしたら君のような勘のいいガキは気づいているかもしれない。
いちいち新しいブランチを切って開発する意味ある？mainブランチでこまめにコミットしてれば良くない？ と。
おおよそ合っている。個人開発においては。
もう一歩先の説明をするため、以降はgithubを含めた手順で説明する。ここを理解するとgit,githubの凄さがわかり始める。
なおgithubの導入の仕方は他を見てほしい。ここでは開発での流れだけまとめる。
githubも利用した開発
githubにリポジトリ作った。さあ開発を進めよう
git checkout -b HOGEHOGE- 既存のファイル1,2を編集(ファイル3は今回は省略)
git add .git commit -m "MESSAGE"
説明は省略する。コマンドだけ見てぱっと理解出来るようになってたら十分。
ブランチで必要な作業終わったのでマージ…しちゃいけない
git push origin HOGEHOGE
ここからgithub特有の流れになる。
ここでローカルリポジトリとリモート(origin)リポジトリを区別して理解しなければならない。
といってもネット上にあるか、自分のPCにあるかというだけ。
pushをすると、ネット上にあるリポジトリに自動的にhogehogeブランチが作成されて公開される。
これでローカルとほぼ同じ状態をネット上に構築できる。
hogehogeもmainと同様の1つのブランチなので、
複数人開発であれば他人がhogehogeブランチにpushして合体させることもできる。ここでは深堀りはしない。
これでリモートリポジトリでマージ…はしちゃいけない？
- githubでプルリクエストを作成する
ここが複数人開発で一番重要？なgithub特有の機能。
この更新したレポート用紙たち…合体させたいんだけど…見てくれない？という要望書を作る。通称プルリク。
「誤字脱字が多すぎ。やりなおし！」「で、このレポートは結局何が言いたいの？」などなどコードをレビューする場となる。
指摘されたら修正して再度push、そしてまた見てもらう。
「多分大丈夫だろう!ﾖｼ!」となったらついにリモートリポジトリのmainへ合体が可能。パーフェクトmainへ進化できる。
このプルリクのテンプレは恐らく現場ごとに色々な形があると思われる。郷に入っては郷に従おう。
既に理解していると思うが、個人開発だと自分しかいないのでプルリク作ったらさっさとマージして問題ない。なのでプルリクの細かい使い方は触れない。
私の場合はやったことをメモ程度に書いたプルリク作って、一晩寝かせたあとに軽く見直してマージしている。
あとはローカルも同じように…？
git checkout maingit pull --rebase
リモートリポジトリでmainに合体した場合は、ローカルで合体はしないようにする。
なぜなら他人がhogehogeにちょっとだけレポートを調整したクリアファイルを追加しているかもしれない。
もしかしたらhogehogeを合体したあと、さらに他人がhugahugaを合体させているかもしれない。
なのでリモートのmainをローカルのmainへ丸ごと合体させたほうが安全である。
ちなみにここの仕組みが2つ目の厄介ポイント。
合体なのにプル…？合体って確かマージでは…じゃあプルリクエストのプルって…？あれ…？
となった。私は。そしてそれを正確に図解出来ている自信がない。
個人的にわかりやすかった記事を貼っておくので参照されたし。rebaseまでまとめて説明している。
git fetch+git merge=git pullだということ、
git rebaseは通常ブランチを合体したという作業レポートが入ったクリアファイルを作るところを、作らず省略して合体することが出来る(=個人開発向き？)、
とだけ覚えておけばなんとかなる。多分。合ってるのか正直わからない。
ただ、1つブランチをマージしたら都度mainは更新しておくようにする。これを忘れると色々面倒なことが起きやすい。
この記事では説明しないが、コンフリクトという言葉は覚えてほしい。あとは調べろください。
ローカルのmainの更新も終わった！あとは？
git branch -d HOGEHOGE- github上でブランチを削除
じゃあね。
個人開発だと影響ないのでさっさと消してOK。消す場所意外と分かりづらくない？
複数人開発だと消していいか一応確認しておいたほうがいいかもしれない？
以上となる。以降は同じく繰り返していく。
ローカルだとスクショだったりファイルをアップして見てもらう必要があるが、githubならURLだけ共有すればそこで全て説明ができる。複数人で開発しても今誰がどんな状況か一目でわかる。
凄くない？gitもgithubもよくこんなもん考えてきれいに構築させるもんだよ。
最後にコマンドだけまとめておく。基本的な開発はこれだけ覚えておけば大体なんとかなる。
ここではgithub基準でまとめて締めとさせていただく。
git checkout maingit checkout -b HOGEHOGE- (ファイルをいじる)
git add FILENAMEgit commit -m "MESSAGE"git push origin HOGEHOGE- (プルリク作ってマージする)
git checkout maingit pull --rebasegit branch -d HOGEHOGE
ちょっと知っておくと便利なやつ
頻繁には使わないけど知ってると便利だなというコマンド。個人的に良かったやつを2つほど貼っておく。
git reset
- わけわからなくなってきたから一旦リセットしたい
- コミットしたらコメントの誤字を見つけた。でも誤字だけのコミット作るのもなあ
なんで一旦クリアファイルにまとめる必要ある？というのはここで生きてくる。
昔のクリアファイルを引っ張り出してその時の状態を再現することも出来る。
いちいちフォルダを複製して保管する必要がない。すごーい！
ただこのクリアファイルの位置はハッシュ値などの文字列で保存されているので、git showなどからテプラを貼ったやつを見てコピペしてくる必要がある。
わかりやすくすることできないの？そう思ったらgit tagを調べるべし。
git stash
- 一旦他のブランチに移動したいけど、今の作業はコミットするほどじゃない
- よく見たら作業してるブランチ完全に間違えてた
gitは保存単位がクリアファイル1つになってしまうので、中途半端な状態で移動することができない。そこでstash。
一時的に作業途中のレポート用紙を避難することができる。私はあまり使わなかったが、いずれ使うことは増えそう。
Discussion