Posted at

SVN から Git(GitHub) へ移行した話と手順まとめ

More than 1 year has passed since last update.


はじめに

少し前に会社のバージョン管理システムを Subversion(以下 SVN)から Git へ移行した。

こういう作業は滅多にやらないので、記憶があるうちに、手順や紆余曲折した点を記載しておこうと思う。

作業自体は Mac で行った。


事前準備


  • パスワードや API キーなどが書いてある機密性が高いファイルは、環境変数に移行する


  • .gitignoreを作成し、バージョン管理しないファイルを記述する

  • Git で無視されないように空のディレクトリに.gitkeepを追加する

  • SVN リポジトリから不要なファイルを削除する(あれば)

  • 作業用 PC に Git をインストールする

  • GitHub にリポジトリを作成する

  • 作業(ワーク)フローを決める(後述)


移行作業


SVN から ローカルにクローン


リモートリポジトリ を origin として登録


Git の更新を読み込む


  • git fetch


Git の更新を取り込む


  • git pull


クローンしてきた SVN のソースを Git リポジトリにコピーする


  • これは GUI でもコマンドでもOK


追加した内容(SVNのソース)をコミットする


  • git add .(.でカレントディレクトリ全て)

  • git commit


Git リモートリポジトリへ push する


  • git push -u origin master

  • 強制的にプッシュしたい場合は-fオプションを代わりに付ける


GitHub のリポジトリにあがっていれば成功


作業(ワーク)フローを決める

実質 git flow と github flow の 2 択だと思うが、

今回は github flow に リリース専用のブランチを足したオリジナルのフローで運用することにした。

つまり、


  • master

  • release

  • feature/dev1

  • feature/dev2

  • ...

といった構成になる。


具体的なワークフロー


  1. master から feature ブランチを作成

  2. feature ブランチで作業を行い、完了したら release ブランチへプルリク(マージ)

  3. release ブランチで本番環境までデプロイ

  4. 本番環境で問題ないことが確認できたら release ブランチを master へプルリク(マージ)

こうすれば master ブランチは常に正常に動作するものだと保証ができる。

release ブランチをデプロイした際に不具合があれば、master ブランチをデプロイすれば良い。

現時点でこのフローで大きな問題は特に起きていない。


最後に

大変だったことをあげるとすれば、関係者が多すぎたこと。

1 つのリポジトリに対して、3 部署 + 1 外注デザイナーが使用しているという構造だった。

移行作業は足並みが揃わないと実施できないため、合意してもらうための根回しとスケジュール調整に物凄く時間がかかった。


その他よく使ったコマンド一覧


ローカルの変更を確認


  • git status


Git の変更をマージ


  • git merge --allow-unrelated-histories origin/master


現在のブランチとローカルブランチを表示


  • git branch


リモートブランチを表示


  • git branch -r


SVN で更新した差分を取り込む(便利)


  • git svn rebase