dbtのベストプラクティスを知る③

前回までの記事 dbtのベストプラクティスを知る① - なむなむ dbtのベストプラクティスを知る② - なむなむ

今回は、ベストプラクティスの中にあった、Git guideを読む。

github.com

Git guide

• ゴールは2つ
  1. 複数のアナリストがコードベースで作業する際にも一貫性を向上
  2. 必要な決定の数を減らすフレームワークの提供

Git branches

• Git branchのネーミングルール
  • feature/name-of-feature
  • fix/name-of-fix
  • refactor/name-of-refactor

Commits

• 命令的なメッセージを持たせるべき
  • "this commit will ..."で始まる以下の内容にする
    • Add MRR models
    • Fix typo in sessions model description
    • Update schema to v2 schema syntax
    • Upgrade project to dbt v0.13.0
• 早く、頻繁に行う
  • コードの一部でも機能したらすぐコミット
  • 将来的に良くないコードを導入してしまったときに、機能したときの状態に簡単に戻すことができる
• お好みで、リモートブランチにPushする前にローカルブランチでまとめる（squash）することもできる

Pull requests

• 作業の機能的なグルーピングをすべき
  • モデル構築と保守作業のような、別々の作業は分けておくべき
• 本文に、コード変更の背景と、そのコードの機能説明を記載する
  • Trelloへのリンク
  • 導入した新機能を説明するdbt docへのリンク
  • 構築したモデルのDAG画像
  • 関連PRへのリンク（モデル変更のきっかけになったBIツールのアップデートなど）
  • 重大な変更の説明
  • コードマージの手順（フルリフレッシュが必要か、リネームしたモデルを落とすか、など）
  • PRテンプレート（サンプル） を使うことで同じことがしやすくなる
• レビュー時間を48時間とる
• 記載者がマージしてよいのは以下の時
  • 少なくともひとりにApproveされる
  • すべてのテストにパスしている
• 書いたコードをシェアするのに最適な方法なので、コードで協働するのに使える
  • 下書きPRも使える

理解。内容もタイトルもテンプレート化すると後々楽だよな