As I understand it the point of migrations is so you can revert the database back to a known state during the last stages of development.
Right now I'm still "fleshing" out my first Rails app and I'm wondering if its ok to roll up my migrations into bigger ones rather than dozens of changes.
移行のポイントは、基本的にデータベースの変更のログを保持することです。これにより、他の開発者がどのような変更が行われたかを知ることができ、開発中に行った変更と同じ変更が実稼働環境に確実に反映されるようになります。
あなたの質問に関しては：確かに。新しいモデルを作成し、数分後に「この列はテキストではなく単なる文字列である可能性がある」と判断した場合は、移行をロールバックし、列を変更してから再度移行します。新しい移行を作成する必要はありません。
他の開発者によってフェッチされた可能性のあるソース管理への以前の移行を既にコミットしているか、運用サーバーに移行を既に適用している場合を除きます。次に、新しい移行を使用する必要があります。
rspeicher への補足として、私は制約を、他の開発者が利用できるようになったかどうかではなく、移行がリリースされたかどうかに制限します。まだプレリリースの場合、開発チームは、使用されている SCM のポストフェッチ フックを使用して、マスター コード リポジトリの更新のために移行を実行する必要があることを通知できます。これは、移行だけでなく、あらゆる構成管理の変更に当てはまります。たとえば、initializers フォルダー内の何かの実装を変更しても、開発モードで実行中のスクリプト/サーバーのインスタンスには影響しない場合があります。これは、ほとんどのテクノロジのほとんどのチームと、継続的インテグレーションの一部の構成に最終的に必要なメカニズムです。または、