103
86

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

HRBrainAdvent Calendar 2023

Day 15

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

Last updated at Posted at 2023-12-14

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

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

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

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

目次

GitHubとSlackの連携:bulb:

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

具体的に何をするか

という感じ。

[GitHubとSlackの接続例]
image.png

[GitHub reminder設定の例]
image.png

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

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

具体的に何をするか

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

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

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

[CIを確認する]
スクリーンショット 2023-12-04 16.26.12.png

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

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

具体的に何をするか

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

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

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

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

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

[コメントで理由を記載する]
スクリーンショット 2023-12-04 16.19.40.png

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

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

具体的に何をするか

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

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

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

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

気をつけます。

スクリーンショット 2023-12-03 午後5.06.48.png

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

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

具体的に何をするか

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

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

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

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

[commitID付きで返信する]
image.png

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

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

公式ドキュメントによると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. それで、大量の差分。

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

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

最後に

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

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

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

おわり。

参考

103
86
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
103
86

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?