「モデル」ブランチは一般的な方法ですか？
すべてのデータベーススキーマの変更に専用のバージョン管理ブランチを用意するのは良いことだと思ったので、他の誰かが同じことをしているのかどうか、そして結果はどうなっているのか知りたいと思いました。
一緒に作業しているとしましょう：
- スキーマモデル/ドキュメント（データベースを視覚的にモデル化して、バイナリである.mwbファイルを使用してスキーマソース（MySQL Workbenchなど）を生成するファイル）
- スキーマソース（.sqlファイル）
- スキーマベースのコード生成
通常の作業方法は機能ブランチを使用することでした。そのため、モデルファイル（データベース固有のファイル）に変更を加えてから、発生する可能性のある競合（またはコードの書き換え）に対処するためにポイント2と3を再生成する必要がありました。
ここで、ワークフローが前のアイテム番号付けと同じように進むと言います。モデルブランチを使用すると、スキーマモデルを他の機能ブランチのバイナリと調整したり、スキーマソースを再生成してコードを再生成したりする必要はありません（その上に人間のコードがある場合があります）。
これを以前に一般的な慣習として見ていなかったのは、私には非常に理にかなっています。
編集：コードに一致するモデルのアサーションとしてブランチマージを期待しています。私はDVCSを使用しているので、長命のブランチや恐ろしいマージを恐れません。機能の分岐も行っています。
私はそれに反対することをお勧めします。データベーススキーマは、他の関連するコードまたはリソースとともに変更されます。変更を適切に追跡できるようにするには、相互にまとまりのある変更をリンクする必要があり、共有コミットがそれを実行するための最良の方法です。
スキーマを別のブランチの下に保持するという提案を検討してください。まず、ブランチを保持して、他の無関係な変更とは無関係に変更をプッシュできるようにします。対応するコードなしでスキーマコミットをプッシュするとどうなりますか？
- 「突然」表示されるコミット履歴を作成します。しばらくすると、それがどこから来たのか、なぜなのかを追跡するのは困難です。
- スキーマのみをコミットする場合は、他の人もコミットできることを忘れないでください。つまり、他の人はプルしてから書き換え/変更することができますyourスキーマの変更でも、すべてのテストに合格します（codeをテストしていないため）。次に、コードをコミットするときに競合が発生しますが、それ以外の場合は回避されている可能性があります。
他の欠点、あるいは利点さえあるかもしれません。しかし、ここにあるこれら2つは、私がこのアプローチを採用しない理由として十分です。
お役に立てば幸いです。
実行中のシステムを構築するすべての種類のソースコードをまとめることをお勧めします（データベースクエリとスキーマを含む）
どうして？なぜなら、コードとシステムを構築するその他のもの（構成、SQL、Readmes、テストなど）の間には常に関係があるからです。変更を加えると、他のアーティファクトも変更するように促されます。異なるブランチ、または異なるリポジトリがある場合、間違いにつながりますが、ブランチAのどのリビジョンがブランチBのどのリビジョンに属しているかを覚えるのははるかに困難です。
以前はリリースブランチを使用していました。その目的のために、すべての開発者は共通の手順に同意しました。
- リリースブランチのバグを修正
- パッチ/差分を作成する
- メインブランチに差分を適用します
マージされた可能性のある変更を複製するため、これはあまり良いことではありません。しかし、これは簡単なアプローチであり、すべての開発者が処理でき、SVN/CVSマージはaの問題になることがあります。
「開発哲学」と使いやすさの観点からは悪い考えです
- 「タスク/機能ごとのブランチ」というルールに違反しています-モデルブランチに関連するタスクがありません（またはタイムスパン内に複数のタスクがあります）
- このブランチは「永遠に生きる」ブランチになります
- 追加永続的機能とマージ-スキーマの変更後にマージが失敗した場合のブランチと壊れたビルド