HackMD
ギトギトのGitHub勉強会 応用編ノート
お前はこのままだと人殺しになる
- なんで？
- 基礎編のやり方だと，バグまみれのコミットをpushされても誰もチェックできない．(困る)
- 誰かがバグをチェックする制度が必要．
これからのやり方
- 以下を繰り返す．
・branchを切る．
・add, commit, push(の3つを何回か繰り返す)
・(git pull origin main)
・プルリクエストを出す
branchとは
- branch・・・枝．
- Gitではプロジェクトを枝分かれさせることができる．
- 実際に枝分かれさせることを「branchを切る」と言う．
- こんなイメージ
- メインのbranch（図だと青いbranch）をデフォルトブランチと呼ぶ．
- デフォルトブランチの名前は大抵の場合，「main」か「master」
- デフォルトブランチの名前を確認するコマンドはこれ
- branchとbranchを合体させることを「マージ(merge)」と呼ぶ．
- どんなブランチも最後にはデフォルトブランチとマージする．
- 枝分かれの仕方のイメージ
- branchの間でファイルの内容は独立している
・例えば，青色のブランチと橙のブランチと緑のブランチに同じ「file.c」があっても，中身は全然違う可能性がある．
なぜbranchを切るのか
- デフォルトブランチとマージする時，プルリクエストというものを出さなければならない．
- 権限のある人がプルリクエストをマージするかどうか選択する．
- プルリクエストを読むタイミングで最終確認ができる．
- ブランチを合体させることをマージと呼ぶ
- メインのブランチをデフォルトブランチと呼ぶ
branchを切る
以下の内容は，チームごとに差があるので，プロジェクトリーダーによく確認を取るようにしてください．
具体的には，
- ブランチの名前の付け方
- マージの手順(実際に実行するコマンド)
で差が生まれます．
- 実際にbranchを枝分かれさせる．
- branchを切るコマンドはこれ．
- ブランチ名は，作業内容にするとよい．
- ブランチ名に日本語を使うとやりにくくてしょうがないので注意．
branchを移動する．
- ブランチを移動するコマンド．
- -bが無くなっているのに注目
- -bをつけるとブランチを新しく作る．
- -bをつけないとブランチを移動するだけ．
- ブランチを移動すると，ローカルのファイルがそのブランチのものに置き換わる．・・・branchの間でファイルの内容は独立しているため．
現在位置を確認する．
- このコマンドで自分が今どのbranchにいるのか確認できる．
- 自分が今どこにいるかを確認するのは無茶苦茶大事．
- 確認しないと，変なところでコミットしたり変なところからbranchを切ったりして無茶苦茶大変．
- 特に，branchを切る前とコミットする前はよく現在位置を確認すること．
- 基本的に，branchを切る時はデフォルトブランチから切る．・・・例外もあるが，初心者がそんな複雑なプロジェクトを担当することはまず無い．
branchを切ったあとは
- add, commit, pushを繰り返し，機能を完成させていく．
- 初めてpushする時だけ，以下のコマンドを使用．
- 「できた！もうデフォルトブランチに組み込んでも問題ない！」と思ったら，以下のコマンドを実行し，デフォルトブランチで起きた変更を取り込む．
または
- 取り込んだらもう一度add, commit, push.
- 取り込むことによって，安全にマージできるようにする．
- pullした結果，デフォルトブランチと衝突し，コンフリクトを起こす可能性もある．
まとめ
git checkout –b (ブランチ名)でブランチ作成．git checkout (ブランチ名)でブランチ移動．git branchで現在位置確認．- ブランチを切ったらadd, commit, pushを繰り返していく．
- できたと思ったら
git pull origin main(master)．そしてadd, commit, push．
プルリクエストを出す．
- プルリクエスト…完成したものをデフォルトブランチに組み込むよう依頼する．
- GitHubから行う．
- GitHubのリポジトリのページを開くと，なんか黄色いのがあるので押す．
・なかったら，リポジトリのページの「Pull requests」タブを開き，Newを押してプルリクエストを作成する． - プルリクエストの名前と本文を書く．
- 本文には，ソースコードで注意して欲しいところや実装について相談したいことや補足事項などを書く．
- 書き終わったら「Create pull request」を押す．
- これでプルリクエストは完成なので，レビューを待つ．
- 場合によっては自分でマージできるけど，してはいけない．
ちゃんと直してこいやモード
- ブランチの完成度が低い(ダメ)と判断されると，プルリクエストが「ちゃんと直してこいや」モードに移行する．
- ちゃんと直してこいやモードに移行した場合，当然作業者はちゃんと直してこないといけない．
- 作業者がadd, commit, pushを行うと,自動的にGitHub上のプルリクエスト上でもそれが適用される．
- ちゃんと直してこいやモードでも，自分で勝手にマージできることがあるが，間違っても自分でマージすることのないように．
Pull request successfully merged and closed
- ブランチが完成していると判断されると，プルリクエストが承認される．
- プルリクエストが承認されて全てが終わったら，以下のコマンドでbranchを戻す．
もしくは
- 忘れると面倒なので注意．
プルリクエストをレビューする
- チームメンバーが出したプルリクエストに問題がないか確認する．
- リポジトリのページのPull requestsタブからプルリクエストを選ぶ．
File changedでレビューをする
- File changedタブを開いてソースコードを確認する．
- 問題を見つけたら，青い+マークを押してコメントを書き加える．
- コメントを書き終えたら，「Start a review」を選択．
- ２つ目以降のコメントは「Add review comment」を選択．
- Start a reviewもAdd review commentも緑なので，緑のボタンを押すと覚えればよい．
Finish your review
- コメントをつけ終えたら，Finish your reviewを押す．(File changed画面の右上にある)
- 本文のところに総評のようなものを書く．
- 下の三つの選択肢は，それぞれ以下のような意味がある．
・Comment・・・ただのコメント．下2つに当てまらない，何とも言えない時に使用．
・Approve・・・OK．大丈夫なので即座にマージする．
・Request changes・・・ダメ．やり直しを要求する． - Submit reviewを押せばレビュー完了．
Request changes
- 上記の3つの選択肢のうち，Request changesを選択すると，プルリクエストが「ちゃんと直してこいや」モードに移行する．
- 許す気になったら，「Approve changes」を選択．
・すごく分かりにくいところにある．以下の図を参照．
全てが完了したら，「Merge pull request」を選択すればデフォルトブランチにプルリクエストが組み込まれる
プルリクエストを実際にデバッグする
プルリクエストを確認する時は，バグを見落とさないようにしなくてはならない．しかし，目で見て全部わかるかというとそういう訳でもない．
手元で実際に動かしてみないとわからないこともあるため，手元にプルリクエストの内容を取り寄せる方法を紹介する．
- まず，プルリクエストのブランチ名を確認する．
プルリクエスト名の近くに書いてある．
- あとは，ターミナルで以下のコマンドを実行するだけでよい．
- 画像の例だと
- このコマンドには，「リモート(origin)からtest_branchを取り寄せ，test_branchという名前をつけた．」という意味がある．
- これでローカルの環境はプルリクエストと同じになっているはず．
- 終わったら元のブランチに戻るのを忘れないように．
まとめ
- 何かする時ははじめにbranchを切る．
- branchを切る時，デフォルトブランチから切る．
- 自分が今いるbranchは常に意識する．
- 完成したら
git pull origin mainとadd, commit, pushしてプルリクエストを出す． - 自分でマージするな．
- 自分でマージするな．
正直，レビューのくだりは，こういう説明を読みながら何回かやればそのうち覚えられるので，今一気に覚えなくてもいい．
？
ぶっちゃけ，revertだのrebaseだのstashだのGitには山ほど機能がある．全部紹介していると本当にキリがないので，とりあえず最低限だけ紹介した．stashは便利なので，慣れてきたら調べてみるとよい．
