チームでGitHubを使うってこういうことなのかなぁ。

こんにちは。
フロントエンドエンジニアのみつです。

チームに入って開発をして、やっと1年目。

でも、個人開発とは違って、チーム開発だからこそ必要な視点。

アドバイスの中で、個人的に今後も大事にしたいなと思ったポイントを集めました。

目次

• GitHubとSlackの連携
  • 具体的に何をするか
• CIが通るまで、レビュー依頼は待つ
  • 具体的に何をするか
• PRを閉じる時は、コメント付き。
  • 具体的に何をするか
• 自分がresolveボタンを押さない。
  • 具体的に何をするか
• レビュー返信に、コミットIDを含める。
  • 具体的に何をするか
• HEADを意識しないと事故るかも。
  • 具体的に何をするか
• 最後に
• 参考

GitHubとSlackの連携

レビュワーとのコミュニケーションコストを下げる！
メンション、コメント、コンフリクトにパッと気が付けるように！

具体的に何をするか

• https://github.com/settings/reminders にアクセス
• GitHubとSlackを接続する
• リマインダーを設定する

という感じ。

[GitHubとSlackの接続例]

[GitHub reminder設定の例]

CIが通るまで、レビュー依頼は待つ

「いい感じ！」と思ってもレビューできる状態じゃないかも！

具体的に何をするか

当たり前っちゃ当たり前なのだろうとは思いつつ・・。

レビュー依頼した時に、「完成〜！レビュ依頼〜！」と確認をせず依頼をし、「CIがこけてます。」のコメントをもらうことがあったので。

ちゃんとCIが通ったの見てから投げるように心を入れ替えました。

[CIを確認する]

PRを閉じる時は、コメント付き。

• あとで見返した時に、なんでCloseしたんだろう？が分かるように！
• 何かしらの対応でPRがOpenし、何かしらの理由でCloseしてるから。

具体的に何をするか

共通のルールとして、Closeする時はこういう風に書きましょうがあればそれでも良いんだろうなと思ったり。

title: '[BUG] <title>'
descriptions: 'XXXで対応することになったのでPR見送り'
・・・

なければ、これぐらいだけでも良いのかも知れないなとも思ったり。

'XXXで対応することになったのでこのPRは見送り'

とにかく、なぜそのPRが閉まることになったのかを明確にするのは大切みたい。

[コメントで理由を記載する]

自分がresolveボタンを押さない。

• レビュワーからコメントがあったものは、レビュワーがresolveを判断する。

具体的に何をするか

resolveボタンを押すのはレビュワー！！

書いたコードに対して、レビュワーが指摘をしたり・アドバイスをしたりしてくれる。

でも、それが修正必要なものなのかimoなのかはさておいて、resolveはそのコメントをいただいた人から貰うべき、と。

todoをこなしていくノリで勝手に閉じてることありました。

気をつけます。

レビュー返信に、コミットIDを含める。

• 複数コメントがある時、このcommitで修正した！を伝えた方がレビュワーが楽みたい。

具体的に何をするか

レビューで指摘をもらい、それを修正する。

ただ、たくさんのcommitを重ねているとどこでその対応をしたか分かりにくい。

（自分のcommitの分け方が酷かったというのはさておき・・・。）

commit prefix（fix, feat...）もつけつつ、どのcommitでこのレビューに対する対応をしたかが分かると良いというアドバイスをもらった。

[commitID付きで返信する]

HEADを意識しないと事故るかも。

• （運用次第で）全エンジニアへのメンションが飛びかねない。

公式ドキュメントによるとHEADとは、下記のようなもので自分の作業中ブランチがどこかということ。

HEADファイルは、現在作業中のブランチに対するシンボリック参照です。
通常の参照と区別する意図でシンボリック参照と呼びますが、これには、一般的にSHA-1ハッシュ値ではなく他の参照へのポインタが格納されています。

$ cat .git/HEAD
ref: refs/heads/master

$ git checkout test

$ cat .git/HEAD
ref: refs/heads/test

「HEADを意識してPRを出す」ということは、どのブランチで作業しているのか（HEADが指しているのか）を意識すること。

具体的に何をするか

PRを出す時は、ここの部分が正しい方向を向いているかを意識してあげる必要がありそう。

自分が問題を起こしたのは、

1. fix-branchを切って修正を行い、fix-branchの修正のために、fix-branch2を作った。
2. チームの他PRがマージされてmainが進んだ。
3. PRを立てる際に、本来fix-branchに向けてPRを出すところをmainに向けてしまった。
4. fix-branch2のdiffは、fix-branchとのものにならず、mainとのdiffを出した。
5. それで、大量の差分。

とにかく、なんの修正をどこに対して反映しようとしているのかは意識しないとやばいなと感じました。

[ベースブランチを変更する]

最後に

まだ開発経験が多いわけではないので、他にも様々なポイントがあるとは思います。

まだまだ頑張っていくぞ〜

あ、あと、GitHub、絵文字もう少し増えるといいなぁ。

おわり。

参考