概要
親愛なるみろりHP読者の皆さんは、緑さんがプログラミングをたまに嗜んでいることをご存知であろう。
GitHub ってのはだな、友達といっしょにプログラムを作るのをサポートしてくれるバチクソ便利なウェブサイトだ。今回はコイツの使いかたをかくぜ。友達といっしょにぷろぐらみんぐするとき、「こういう感じでやるよー」って見せる記事がほしかったのだ。
だから、この記事は、開発リーダーではなくて参加者向けってことになるよ。
開発フロー
リポジトリの管理者から招待を受ける
招待メールが送られてくるはずだから、緑色のボタンを押して参加しよう。
リポジトリを clone
リポジトリのページを訪れて、 clone しよう。最高の Git リポジトリ管理ツール、 GitHub Desktop があるから四の五の言わずに使うのだ。
リポジトリを DL 出来たら、 GitHub Desktop では↑こうなる。
手をつける issue を選ぶ
管理者と相談して、手をつける issue を選ぼう。 Issue はこれから追加すべき要素、解決すべきバグの一覧だ。
↑こんなふうに、作業前にはコメントをする。
Issue 用の branch を作る
まずローカルの master branch を最新化しよう。これから master branch から作業用 branch を作るが、大本である master branch が古くなっていたら目も当てられない。古くなっているというのは、ローカルの master branch とリモートリポジトリの master branch に差異があるということだ。 GitHub Desktop の fetch ボタンを押して、リモートリポジトリの情報を引っ張ってこよう。
GitHub Desktop で branch を作ろう。 Branch 名は feature/[Issue 番号]_[好きな名前] だ。今回であれば feature/#5_django-axes。
作業をして commits を作る
Commit は小さな単位で行うこと。ひとつの commit では、ひとつのことだけをする。コミットメッセージは [Issue 番号] [コミット絵文字] [具体的な変更内容] だ。今回であれば……画像参照。
どの絵文字をつければよいかは下記リンクに記載がある。ようは、 commit の内容に応じた絵文字を記載するってことだ。これにより、ひとつの commit に複数の変更……大きすぎる変更が含まれることを防止できる。たとえば機能追加とバグ修正を混ぜたら絵文字に sparkles を使うか bug を使うか迷うだろう? その時点で commit が大きすぎることが分かるのだ。
作業 branch を最新化する
Issue を解決できたら、自分の変更を master branch に取り込んでもらうよう管理者に依頼するわけだ。しかし master branch がすでに変更されており、このまま自分の変更を merge すると、その機能を破壊してしまうかもしれない。まずは master branch の変更を自分の branch に取り込もう。 GitHub Desktop から、 update from master を行う。
そらきた、 conflict が発生している。作業 branch の担当者は、すべての conflict を解消し、 master branch に取り込んでも問題ないようにする義務がある。 master branch は、もっともバグの少ない状態にしなければならない。もちろん conflict が発生しない場合もある。そのときは次へ進もう。
Conflict 解消の方法は割愛する。とにかく、自分の変更が master branch を破壊しないことが大事なのだ。
Push して PR(pull request)を作る
こうして問題のない branch を作れたら push をする。
そのあと PR を作る。 PR では、管理者に、どういう変更をしたかを知らせるメッセージを書く。管理者もヒマではないのでわかりやすく書いてやろう。
レビュー依頼のコメントをしたら、管理者のレビューを待とう。
レビューを反映
管理者がレビューすると、こんなふうに出てくる。それぞれにコメントを打とう。
そうしたらコードを修正して、 commits を作り、また push だ。
Merge されたら branch を削除
どうやら管理者のレビューが終わり、無事自分の作業 branch が master branch に merge されたようだ。 GitHub 上では、 PR が merge された旨が記述され、関連 issue(今回は #5 のことだ)は管理者によって close される。
そうしたら GitHub Desktop でローカルの作業 branch も削除しよう。
ここまでがワン・フローだ。また次の issue を選び、 branch を切ろう。
Slack に通知
こんなフローがあったところで通知がこなけりゃ意味ないので Slack に通知しとく。これについては参考リンクだけ付して割愛する。
