Subversion を Git へ移行したい (そして共有方法として GitHub を使いたい) 場合に考える観点をあげてみます。
- チームに Git にくわしい人がいるか? いない場合、聞く先があるか?
- チャットに git ルームをつくるなど
- 習熟度に不安があったら、やってはいけないことリストとこうすべきリストの整備が初期の混乱を防ぎます
- force push 禁止
- ブランチはリモート追跡ブランチからきる
- git push/git pull のときのオプション指定のルール
- などなど、チームで決めて育てるといいと思います
- 利用開始前チェックテストをやってみる
- origin/master と origin master の違いは? git reset の挙動の説明など
- クリアするために最低限の基礎知識がそろうのでおすすめ
- テスト自体もチームでつくると過程で学べる
- リリースフロー
- デプロイ方式への影響は?
- デプロイ時の Git リポジトリへのアクセス管理のプラクティスとしては、ローカルに自分の Git 用秘密鍵を持ち、それをデプロイサーバまで ssh agent forward するというのがあります。ローカルの鍵の権限でさわれるリポジトリはすべて pull できるので、デプロイサーバのアカウントが共有の場合なども自分自身が可能な操作に依存して作業を行えます。
- su したときに鍵が引き継がれないという場合、
sudo ssh -A hoge@localhost
するというハックがあります。ただ、基本的に su して共通のユーザーにならないといけない理由はファイルアクセス上の都合なので本当に su が必要か (個人ユーザーで書き込み権限持たせた場合の不都合はなにか) を検討して個人ユーザーのみで完結できるように運用を設計するのが本筋となります。
- ワークフローとブランチ戦略とインテグレーションテスト環境
- CI のための Git アクセスをどのように管理するかのプラクティスとしては、マシンユーザーを使うのがおすすめ。jenkins というようなアカウントにほぼすべての repo の Read を持たせて Jenkins ホストの jenkins 起動 Linux アカウントで生成した public key (たとえば /home/jenkins/.ssh/github.com/id_rsa.pub ということです) を登録してやると、Git plugin で git clone/pull できるようになります。なお、権限がオールマイティになってしまうので Jenkins の認証情報管理の機能を使って ssh 鍵の管理をしてやるのがベターです。
- 共用開発サーバとのコンフリクト
- ワークツリーを共用しているかぎり、カジュアルにブランチが切り替えられません
- 対処として、個人開発環境を準備したり、1つのホストでマルチプロセスでアプリサーバを立ち上げたりします
- デプロイして本番サーバへあげ、そのまま動くはずのリソースが管理されているか
- よくあるのは、デプロイサーバ上でだけ編集されコミットされていないファイルがあるケース
- Subversion のコミットログは残すか移行するか
- よほど今までちゃんとやってたのでないかぎり、Subversion リポジトリを Read only で残し、Git リポジトリは初期化された状態からスタートするのが移行作業の心理的な負荷が少なくて楽です。履歴に価値がありそうならコミットを移行することも可能です。