Salesforce 開発で試している git フロー (rebase & force push)

git での管理が当然のようになっている昨今ですが、直近携わっている Salesforce の開発ではどうしたら良いか・・・ベストプラクティスが分からずにおります。
そこで、直近 Salesforce の開発で試しているフローを簡単にまとめて晒してみることにしました。
(そして、もっと良い方法をご教示頂ければ幸いですmm)

1. 前提

ブランチ構成がこんな感じ

master   (リリース用)   1 ---> 2 ---------> 3
topic    (バグ修正用)          |\---> @ ---/
feature1 (機能1追加用)         |\--------------> A ---> B
feature2 (機能2追加用)          \--------------> C ---> D

補足

• 状況・開発体制・ルールなど
  • Salesforce 組織は本番稼働中。運用保守業務 + 機能追加開発 のため、Sandbox (適宜リフレッシュ済) のソースを git 管理
  • 少数 (数名規模)
  • マージはプルリクベース。マージできるのは一人 (レビュアー) のみ
• ブランチ
  • feature1, 2 が master にマージされるのは、大分先である（ブランチの生存期間が長い。両方共1ヶ月以上とか）
  • その間 master には、保守作業により topic ブランチが複数作成・マージされる

2. 結論

• feature ブランチの生存期間が長いなら、master の最新コミットから rebase する
• そして、force push する

$ git checkout feature1
$ git rebase master
$ git push origin -f feature1
(feature2 についても同様)

こうなる

master   (リリース用)   1 ---> 2 ---------> 3
topic    (バグ修正用)           \---> @ ---/|
feature1 (機能1追加用)                      |\---> A ---> B
feature2 (機能2追加用)                       \---> C ---> D

3. なぜこのように (rebase & force push) しているのか

topic を feature1, 2 にマージするのはダメなの？

• トピックブランチと統合ブランチでの運用例【ブランチ】 | サルでもわかるGit入門 の [A successful Git branching model] のように、ツリーが複雑な形になるのでは・・・
• そして、いざ feature を master にマージする時点で、予期しないバグ (topic で修正したはずの箇所が、マージミスによって再発してしまった等) が紛れ込んだ場合、追跡するのが大変になるのでは・・・

と懸念しました。

一方 rebase ならば、ツリーの形がすっきりしている (常に最新から派生していることがわかる) ため、そのような事態になっても比較的なんとかなりそうです。

マージも rebase も、コンフリクトが発生する時は発生するわけですが、rebase 時は各コミットに対してコンフリクトの解決を迫ってくれるのもポイント高いです。
(feature1 を、コミット 3 から rebase する際 A, B 両方共コンフリクトしたとして、まずは A に対してコンフリクト箇所を提示。次は B に。B が解決したら rebase 完了)

force push は危険と聞いたことがあるので、基本的にしない方が良いのでは？

feature ブランチは生存期間が長い & 複数人で開発しているという背景があり、origin へ push は既定路線という事情です。
これを rebase するわけですから、force push は避けられません。

できれば、force push せずにやれたらいいなと思います。しかし、携わっているプロジェクトについては、ツリーをシンプルに保つことで品質を上げること優先と考えています。
このため、force push もやむなし (代わりに、slack でメンバーに「rebase しといたから stash, fetch, pull 等よろしくオナシャス」通知して、何かあったらヘルプを求める運用) にしています。

4. まとめ

今の所、この方式でとくに大きな問題は起きていません。(メンバーのスキルが高いおかげもめっちゃある)
また色々改善点が見えたら、追記していこうと思います。

ちなみに、Salesforce の開発では Apex や Visualforce ページ, コンポーネントだけでなく、メタデータも管理する必要があります。また、年3回 (だったような・・・) のバージョンアップに伴い、担当した箇所以外の差分も発生します。さらに、本番・fullsand, sandbox といった環境毎に微妙にメタデータが異なっている (要素の並び順が違う・バージョンが違う・・・など) ようなこともあります。
このため、「本番で動いているものが正。ソース管理もそのへんに気をつけて」ということがあったりします。(そうでもない...?)

Docker のように「ソースを完全に git に管理し、これベースにデプロイ」という環境に慣れた身には、手順書ベースで業務を行っていた遠い昔に戻ったようで何とも切ない感じを覚えることがあります。。。
が、SalesforceDX もボチボチ GA になりそうな雰囲気になってきましたので、「ソースベース」で楽しく開発できる日を期待していきたいところです