Laravel migrate - multiple migrations (files) in one go

Question

Say, I have multiple migration files updating single table.

e.g.

2016_03_20_072730_create_tasks_table.php
2016_03_20_075467_create_tasks_table.php

... which came from repo by different team members. Each is adjusting something in table, e.g. adding a column.

When I try to:

php artisan migrate

I get error:

PHP Fatal error:  Cannot declare class CreateTasksTable, because the name is
eady in use in U:\www\b10\database\migrations\2016_03_20_072737_create_tasks_
le.php on line 30


  [Symfony\Component\Debug\Exception\FatalErrorException]
  Cannot declare class CreateTasksTable, because the name is already in use

How should one deal with situation as described above?

EDIT

Here is the code:

2016_03_20_072730_create_tasks_table.php:

class CreateTasksTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
       Schema::table('tasks', function ($table)
       {
           $table->string('task1');
       });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('tasks');
    }
}

2016_03_20_075467_create_tasks_table.php:

class CreateTasksTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
    Schema::table('tasks', function ($table)
        {
            $table->string('task2');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('tasks');
    }
}

Answer 1

Each migration has to have a unique class name. Rename the second one to something more sensible, such as 2016_03_20_075467_add_task2_to_tasks_table and AddTask2ToTasksTable, then run composer dump-autoload to make Laravel find the changes. Now you can migrate.

Edit: Now that both migrations' code has been edited into the question, I can see that the first migration has the same problem, and should be renamed in the same manner. There's probably an initial create migration sometime further back. You should stop naming editation migrations anything with create, since you aren't actually creating the table.