這篇算是 Heresy 這邊透過 Docker 來架設 GitLab server 的一些後續，真要說的話，應該是之前《GitLab 升級到 13 的筆記》的延伸。
GitLab 在 13.0 的時候，把「Design Management」（官方文件）開放給免費的使用者使用了。這項功能的目的，主要應該就是讓使用者可以在 issue 中上傳圖檔，方便討論。
不過，對 Heresy 這種是從 GitLab 11 升級上來的人來說，這項功能預設是不能用的。而且還會在 issue 那邊顯示警告，看起來滿煩的。 XD
而為了把它消掉呢，就認真看了一下他的需求，發現他需要：
- 需要開啟 Git Large File Storage（Git LFS）的功能
- GitLab server 管理者要先開啟，專案內可能也需要設定
- 專案要使用 hashed storage
開啟 Git LFS
管理者要開啟 Git LFS 的支援的話，可以參考《GitLab Git Large File Storage (LFS) Administration》這份文件。
以 Heresy 這種使用 Docker 來架設的人來說，基本上就是去修改 /etc/gitlab/gitlab.rb 這個檔案，找到
# gitlab_rails['lfs_enabled'] = true
把它前面的「#」拿掉就可以了。
而如果想要另外設定儲存的位置的話，也可以調整下面的「gitlab_rails[‘lfs_storage_path’]」。
修改好後，執行 docker restart gitlab 把 GitLab 的容器重啟，就可以啟用 Git LFS 了。
之後，在個別專案的「Settings」、「General」的「Visibility, project features, permissions」裡面，就可以看到「Git Large File Storage (LFS)」的選項了。
如果還沒有開啟的話，把它開啟再儲存就可以了。
升級為 Hashed Storage
GitLab 13 的時候，已經將 hashed storage 預設開啟、並將傳統儲存方式標記為「棄用」（deprecated）、並將在 GitLab 14 的時候全面轉移了。
而要判斷一個專案是否是採用 hashed storage，則需要用管理者的帳號，在「Admin Area」中「Overview」下的「Projects」中，確認「Gitaly relative path」的形式。
像下圖這樣，顯示「@hashed/….」，就代表是使用 hashed storage。
但是在 Heresy 一路從 GitLab 11 升級上 GitLab 13 的過程，GitLab 似乎並不會主動地將既有的專案儲存方式進行升級。
而如果要手動將所有專案都升級成 hashed storage 的話，則需要進入 GitLab 的 Docker 內，執行下面的指令：
gitlab-rake gitlab:storage:migrate_to_hashed
這個指令需要一定的時間，所以要稍微等一下。
等指令完成後，就完成所有既有專案的轉移了。
理論上都處理完後，issue 中的「Design Management」就可以用了。
而它的好處…應該就是有版本控制，可以快速地檢視不同的版本了吧？