前言
在實際開發中，我們可能經常會遇到一個項目會建立兩個 Laravel 項目，一個是面向用戶的 web/API，一個是管理員后臺，這兩個項目一般情況下是共用一個數據庫的，那么我們的 migration 可以共用嗎？該怎么操作？
Migration就相當于數據庫的版本控制工具，可以使用
php artisan migration
生成數據庫表，但前提是要在database目錄下有相應的表的PHP文件
下面話不多說了，來一起看看詳細的介紹吧
在各項目里建各自 migration
我們先在 web/API 和 admin 里都建各自的 migration：
## web 目錄
php artisan make:migration foo
# Created Migration: 2018_09_19_144940_foo
php artisan migrate
# Migration table created successfully.
# Migrating: 2018_09_19_144940_foo
# Migrated: 2018_09_19_144940_foo
php artisan migrate:status
# +------+-----------------------+-------+
# | Ran? | Migration | Batch |
# +------+-----------------------+-------+
# | Yes | 2018_09_19_144940_foo | 1 |
# +------+-----------------------+-------+
## admin 目錄
php artisan make:migration bar
# Created Migration: 2018_09_19_145255_bar
php artisan migrate
# Migrating: 2018_09_19_145255_bar
# Migrated: 2018_09_19_145255_bar
php artisan migrate:status
# +------+-----------------------+-------+
# | Ran? | Migration | Batch |
# +------+-----------------------+-------+
# | Yes | 2018_09_19_144940_foo | 1 |
# +------+-----------------------+-------+
# | Yes | 2018_09_19_145255_bar | 2 |
# +------+-----------------------+-------+
從 artisan migrate:status 的結果來看，兩個 migration 都正常執行了，接下來我們試一下回滾操作。
先直接在 web 目錄執行
php artisan migrate:rollback
# Migration not found: 2018_09_19_145255_bar
報錯了，因為在 web 項目里找不到 bar 這個 migration 文件；那如果我們剛剛是直接在 admin 目錄執行，是能夠正常回滾的，但是如果我們指定回滾兩個版本：
php artisan migrate:rollback --step=2
# Migration not found: 2018_09_19_144940_foo
# Rolling back: 2018_09_19_145255_bar
# Rolled back: 2018_09_19_145255_bar
這次回滾操作也是有問題的，只回滾了一半。
所以我們應該按照 migrate 的相反順序執行回滾，即先在 admin 執行一次，然后再到 web 里再執行一次。我們上面的實驗很簡單，要記住這些順序也不難，可是在實際的項目中，你的 migrations 就比這個復雜多了，而且只通過 migrate:status 你也看不出來執行順序到底是怎么樣的，所以在各個項目里各自維護各自的 migrations 似乎行不通...
共用一份 migration
上面的實驗我們可以知道，我們在執行 artisan migrate 的時候，Laravel 會讀取 migrations 目錄里的文件和數據庫里的記錄，然后再執行相應的操作（并記錄這次操作）；回滾的時候 Laravel 會讀取數據庫中的記錄，然后執行 migrations 目錄里相應的文件中的 down 方法。
而當 migrations 分散在不同的項目（目錄）里的時候，不管你在哪個項目中執行 migrate:rollback 時，都可能只有一部分 migration 文件被加載進來，因此會造成一些奇奇怪怪的問題。
那我們可以將所有 migrations 放在同一個地方，怎么操作呢？再建一個新的項目似乎有點麻煩了...我們先看看幫助吧：
php artisan migrate --help
Description:
Run the database migrations
Usage:
migrate [options]
Options:
--database[=DATABASE] The database connection to use
--force Force the operation to run when in production
--path[=PATH] The path to the migrations files to be executed
--realpath Indicate any provided migration file paths are pre-resolved absolute paths
--pretend Dump the SQL queries that would be run
--seed Indicates if the seed task should be re-run
--step Force the migrations to be run so they can be rolled back individually
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
--env[=ENV] The environment the command should run under
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
果然有我們想要的東西：--path 和 --realpath，先來看看這兩個參數是什么用途：
--path[=PATH] 指定 migrations 文件的路徑
--realpath 表示 --path 指定的路徑為絕對路徑
那我們在進行 migrations 操作的時候，指定同一個路徑，那就可以共用 migrations 了：
php artisan make:migration foo --path="../admin/database/migrations"
# or
php artisan make:migration foo --path="/the/absolute_path/to/admin/database/migrations" --realpath
# migrate
php artisan migrate --path="../admin/database/migrations"
# migrate:rollback
php artisan migrate:rollback --path="../admin/database/migrations"
注：當你不帶 --realpath 的時候，path 是以項目的根目錄為 / 的
總結
所以，當我們需要在多個 Laravel 項目中共用 migrations 的時候，最好的做法是通過 --path 指定 migrations 文件的目錄，這個目錄可以是一個獨立的 git repo，也可以是其中一個 Laravel 項目（我個人推薦放在其中一個項目中，采用獨立的 git 分支），這樣既可以共用 migrations，在團隊協作的時候也不會混亂和出現沖突
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。
您可能感興趣的文章:- Laravel 5.4因特殊字段太長導致migrations報錯的解決
- Laravel 5框架學習之數據庫遷移(Migrations)
- 解決Laravel 不能創建 migration 的問題
