It's true what you said, but there are situations when I prefer to continue the migrations, like when the DB already contains a big part of the migrations (but the migrations table is not synced with that). And there are other cases...that's why I proposed to be an option, not mandatory.

Other useful flag would be something like --start-from=migrations_XXX so we could run all migrations from a point forward.

Why the hell would your DB already contain the migrations but not the actual records in migrations? It is your fault that you're doing DB modifications outside of Laravel migrations without rolling them back or creating a new DB.

There's something majorly wrong with your development process. Don't edit existing migrations. Don't do schema changes manually or roll them back - that's why rollbacks exist.

Errors about columns already present in the table..I know i could modify the migrations adding something like
if (! column_exists('new_column') ...

but there are many migrations and i think there should be an easier way to just ignore this and continue.

I get this error many times, here is how to solve it.

First, there is an up method and down one in the migration class.

The up is for creating the table/columns and down for the opposite operation.

If you have duplicate column in your db, you need to do one of these options:

• Modify the existing column, see this (Not recommended)
• Rollback your database to previous migration to undo the previous migration operation or use step flag to get the level you want (recommended)
• Create new migration to drop the column that is already exists on the DB (not sure why you do that, but still an option).

In depth explanation for the 2nd option:

Let's say you have articles table migrated, and you need to add some column in it (e.g excerpt) You need to add a migration to add this one right? Something like: XXX_add_excerpt_column_to_articles_table and you will add the column to the migration file, BUT make sure to drop the column in the down method, because when you run php artisan migrate:rollback it will look at the down method first to drop the columns.

An example:

    public function up()
    {
        Schema::table('articles', function (Blueprint $table) {
            $table->string('excerpt');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('articles', function (Blueprint $table) {
          // when you rolling back the migration, laravel will look at this column/columns and drop.
            $table->dropColumn('excerpt');
        });
    }

Hope this answer helps you.

Thank you man, I already know this stuff...But i don't want to rollback, i have data in the DB which was not seeded so i don't want to lose it. WHY is it so hard to understand that SOMETIMES i just want that damn migration to continue ??? it's my choice if i do so!

Sorry to hear that @pildit, the only thing left then, is to extend the migration command logic and make it as you like.

Here:
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Database/Console/Migrations/MigrateCommand.php

can be solved by adding specific flags like --skip-if-table-already-exists