Skip to content

Instantly share code, notes, and snippets.

@akuraru
Last active Dec 20, 2019
Embed
What would you like to do?
ユビレジでのgit、githubの使い方

ubiregiの情報共有システムからコピペして少し加工したものです

思想

スクラムでは透明性・検査・適応の三つの柱からなっている。 自分の作業を透明性を上げ、レビュー(検査)をして、修正(適応)していくのを素早く行なっていくために今の方法を取っている。より良い方法があれば改善していきたい。

git

意味のある単位で細かくコミットする

  • 自分のやったことをわかりやすくする
  • レビューしやすくする
  • 細かい分にはあとでまとめられるけれど、まとまったものは分けにくい

コミットメッセージはわかりやすく

  • 変更内容とコミットメッセージを一致させる
  • コミットメッセージが複数行書きたいならコミットを分ける
  • x「指摘の修正」→何をどう修正したかを書く

ブランチ名はわかりやすいが短く

  • 基本的に被らなければOK
  • やっていることを表すようなブランチ名が好ましい
  • 1〜3単語くらいを-(ハイフン)区切りにする事が多い
  • 名前/をつける人もいる

いくつかの機能をまとめる場合にfeatureブランチを作ろう

  • 常にリリースできるような作り方を推奨しているが、まとめてリリースしないと機能として役に立たない・壊れる時に使う
  • feature/ + 1〜3単語のブランチ
  • featureブランチに対してPRを出せるようにして、細かくPRが出せるようにしている

github

タイトルと詳細をわかりやすく書く

  • タイトルは解決したいことを書く
    • 「<ある問題>を修正した」とか「これこれをできるようにした」とか
    • 実装に依存したことを書かない
  • 何も知らない人がレビューしてわかるような詳細であるか
    • 「#xxx の修正した」はダメ🙅‍♀️
    • 問題の内容、修正方針、実装方針を書いておくといいでしょう
    • 元のissueやストーリーのリンクを貼る
    • 解決方法が変わった場合その都度更新する
    • UIを変更した場合はbefore, afterのスクショを貼る

close #xxx をつけましょう

細かくPRを出しましょう

  • 小さい方がレビューしやすい
  • 素早くレビューに出せた方が軌道修正を早く行える

途中でもPRを作りましょう

  • WIPのラベルをつけてPRを作る
  • 30分以上かかってるならPRにしておいた方がいい
  • 落ち着いて見直すのに便利
    • 調査が足りていない
    • 設計が間違っている
    • PRが大きすぎる
  • 相談とかペアプロするのに便利
  • 優先度が下がってしばらく放置するときに便利
  • PC壊れた時のバックアップとしても便利

masterにリベースしよう

  • PRを出す時や時間が経ってしまった時は最新のmasterにリベースを行ってからPRを出す
    • いらない変更が混じらない
    • コンフリクト回避する
  • 気にせずgit push --force

連続したPRの出し方

  • 1つ目のPRの後にコミットを積んだ2つ目のPRを出したい場合の方法
  • 2つ目のPRのマージ先を1つ目のPRのブランチにしてPRを出しておく
    • 差分が見やすくなる
  • 1つ目がマージされたらmasterに変更する

レビューからマージまで

レビューしてもらいたいものにはラベルをつける

 誰かのApprove(承認)なしにマージしてはいけないルールになっています。Approveされるためには、レビューを受ける必要があります。reviewerを追加しましょう。review-neededのラベルがついているものがレビューの対象になります。ラベルをつけてレビューされるのを待ちましょう PullRequestにレビュアーをアサインしたら自動的にラベルを付ける設定がされているレポジトリでは自動的に付きます)。何らかの理由で急いでマージする必要があれば、Slack等でお願いしましょう。  

change-requestedに対応する

レビューがあった場合にchange-requestedなることがあります。レビューにしたがって変更を加えて、change-requestedを外してreview-neededをつけましょう。 レビューの内容に異議がある場合は、レビュワーと協議しましょう。より良い方法を協議した上で変更を加えましょう。

レビュー中はスカッシュしない

  • 修正差分が内容がわかりにくくなる
    • バッサリ作り直す時はコミット積み直す時もある(状況による)
  • レビューが終わって修正コミットが多い場合は整理してコミットし直すことはよくある

他の人のPRをレビューしましょう

  • 自分のPRをレビューしてもらいたいと同じように他の人もレビューしてほしい
  • チームとして成果を出すためにレビューも大事
  • 勉強にもなる

自分でマージする

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment