ubiregiの情報共有システムからコピペして少し加工したものです
スクラムでは透明性・検査・適応の三つの柱からなっている。 自分の作業を透明性を上げ、レビュー(検査)をして、修正(適応)していくのを素早く行なっていくために今の方法を取っている。より良い方法があれば改善していきたい。
- 自分のやったことをわかりやすくする
- レビューしやすくする
- 細かい分にはあとでまとめられるけれど、まとまったものは分けにくい
- 変更内容とコミットメッセージを一致させる
- コミットメッセージが複数行書きたいならコミットを分ける
- x「指摘の修正」→何をどう修正したかを書く
- 基本的に被らなければOK
- やっていることを表すようなブランチ名が好ましい
- 1〜3単語くらいを-(ハイフン)区切りにする事が多い
名前/をつける人もいる
- 常にリリースできるような作り方を推奨しているが、まとめてリリースしないと機能として役に立たない・壊れる時に使う
feature/+ 1〜3単語のブランチ- featureブランチに対してPRを出せるようにして、細かくPRが出せるようにしている
- タイトルは解決したいことを書く
- 「<ある問題>を修正した」とか「これこれをできるようにした」とか
- 実装に依存したことを書かない
- 何も知らない人がレビューしてわかるような詳細であるか
- 「#xxx の修正した」はダメ🙅♀️
- 問題の内容、修正方針、実装方針を書いておくといいでしょう
- 元のissueやストーリーのリンクを貼る
- 解決方法が変わった場合その都度更新する
- UIを変更した場合はbefore, afterのスクショを貼る
- 対応するissueがある場合は「close #2914」をつける
- これをつけるとPRがmasterにマージされると自動的にissueが閉じられます。
- https://help.github.com/en/articles/closing-issues-using-keywords
- 小さい方がレビューしやすい
- 素早くレビューに出せた方が軌道修正を早く行える
- WIPのラベルをつけてPRを作る
- 30分以上かかってるならPRにしておいた方がいい
- 落ち着いて見直すのに便利
- 調査が足りていない
- 設計が間違っている
- PRが大きすぎる
- 相談とかペアプロするのに便利
- 優先度が下がってしばらく放置するときに便利
- PC壊れた時のバックアップとしても便利
- PRを出す時や時間が経ってしまった時は最新のmasterにリベースを行ってからPRを出す
- いらない変更が混じらない
- コンフリクト回避する
- 気にせずgit push --force
- 1つ目のPRの後にコミットを積んだ2つ目のPRを出したい場合の方法
- 2つ目のPRのマージ先を1つ目のPRのブランチにしてPRを出しておく
- 差分が見やすくなる
- 1つ目がマージされたらmasterに変更する
誰かのApprove(承認)なしにマージしてはいけないルールになっています。Approveされるためには、レビューを受ける必要があります。reviewerを追加しましょう。review-neededのラベルがついているものがレビューの対象になります。ラベルをつけてレビューされるのを待ちましょう PullRequestにレビュアーをアサインしたら自動的にラベルを付ける設定がされているレポジトリでは自動的に付きます）。何らかの理由で急いでマージする必要があれば、Slack等でお願いしましょう。
レビューがあった場合にchange-requestedなることがあります。レビューにしたがって変更を加えて、change-requestedを外してreview-neededをつけましょう。
レビューの内容に異議がある場合は、レビュワーと協議しましょう。より良い方法を協議した上で変更を加えましょう。
- 修正差分が内容がわかりにくくなる
- バッサリ作り直す時はコミット積み直す時もある(状況による)
- レビューが終わって修正コミットが多い場合は整理してコミットし直すことはよくある
- 自分のPRをレビューしてもらいたいと同じように他の人もレビューしてほしい
- チームとして成果を出すためにレビューも大事
- 勉強にもなる
- 自分の変更は自分で責任持ってマージする
ブランチも消しましょう自動で消えるようになりました