把團隊的專案跑migrate，為什麼卡住了？-應該是因為有人跑了migrate以後，又改檔案了吧

開始跑專案以後，我們才學會的事

組員A: rails db:migrate 後，又修改檔案

繼上一篇的操作，我又學會了另一件事，這篇來講一下這個議題。
這個狀況是團隊協作時發生，自己做的project不會發生的。

我會用事情發生的時間順序描述一下這狀況：

1. 組員A從devise套件做了一個檔名 devise_create_users.rb的migration檔。
   可以稍微看上圖的第25~28行，這時候還是註解起來的。
   因為組員A想說，devise套件的confirmable還不需要用到，於是就在這樣的migration檔的記錄下，下了指令 rails db:migrate 。
   而 schema.rb 檔留下了這次migrate的生成紀錄，這一刻， schema.rb 檔裡並沒有confirmable的那幾行。
2. 經過了2天的進度，組員A忽然發現他需要做devise的confirmable。
   於是他把前天做過 db:migrate 的migration檔裡，註解的confirmable解開來。把註解解開，所以他

對「已經做過 db:migrate 的migration檔」進行了「修改」。
這是新手常踩的雷。

其實也不是不能修改，也許可做 db:rollback ，然後再對這個migration檔修改，再 db:migrate 一次。

3. 接著，他以為註解打開就可以做了，於是進行了 db:migrate 。
然後他發現他要的欄位都沒加入 schema.rb 。

4. 下意識地，組員A想到，可以做一個 add_column_to_users 的migration檔，然後進行 db:migrate ，他成功把他要加的欄位加進 schema.rb 檔。
於是這一連串的動作，產生了

兩個migration檔同時存在，且檔案要建立的欄位有重複到的狀況。

請參照下面兩張圖片。

到目前為止，因為還只有在組員A的本機端操作，所以還沒有發現問題。
直到push到團隊專案的GitHub上。

組員B: 拉下進度後， db:migrate 卡住

接著另一位組員B，從團隊GitHub拉下組員A的進度。
然後 db:migrate 就噴錯了。

如果你看到這邊，感覺不是非常能了解我說的地雷的話，建議看看下面這教學：Rails 怎麼知道哪些 Migration 有做過？
然後再來看一次我的文章，順便拍個手，表示你學會了。

我以前不太了解，什麼是「一本書可以看好幾遍」，最近我體會到了。

龍哥：「你要痛過才會知道」

好喔，我知道了。

References

Rails 怎麼知道哪些 Migration 有做過？