When developing database changes, users have the option to use Flyway Desktop or the Flyway Command Line to complete development tasks like:

• Setting up a project
• Importing projects from SQL Source Control or Source Control for Oracle
• Saving development database changes to the Schema Model on disk
• Preparing for a deployment by generating migration scripts

Some teams have setup a process to automate these development tasks so developers don't have to change the way they currently work.  This could include capturing all development database changes on a certain basis (e.g., at the end of each day, end of sprint, right before a release, kicked off from a manual step).  Be aware that if you are using a shared development database, you are capturing everyone's changes and the commit history will not identify exactly who made each change. 

Some teams decide to capture the Schema Model as part of a Pull Request (PR) (also known as a Merge Request (MR) in GitLab), which can capture who made the change if it's the same person that created the PR/MR.   

Some teams still have the developers use Flyway Desktop to capture the Schema Model changes and accurately record the object level history in Git.  They can enter Work Item or Jira IDs as part of the commit message.  They then use an automated process on PR/MR or when merging from a development branch to a release candidate branch to generate a migration script (versioned and optionally undo migration scripts), which can then be reviewed and edited by a database developer lead or DBA responsible for how to deploy those changes.  

We hope the following examples for using the command line to complete these tasks help you get started with defining a process that works best for your team:

• Setup and baseline a project via the command line (cli)
• Use the CLI to save database changes to the Schema Model
• Use the CLI to generate migrations