GitとGitHubをプロジェクトに導入する際にやったことをメモする。
プロジェクトの初期から参画し、
ある程度の舵取りができる機会に恵まれた。
その時に得た知見を記述する。
プロジェクト参画時の状況としては以下の通り。
まず最初にブランチ戦略を決定する。
Gitでよく使われるブランチ戦略は数種類ある。
Git-Flow、Github-Flow、GitLab-Flowなど。
今回の導入には、Git-Flowを採用した。考慮した点は以下の通り。
数か月ごとにリリースがある。
数か月ごとにリリースがあり、リリースされたものはエンドユーザに公開されて実践に即した動作テストに提供される。
次のリリースまでの間は、次々と機能追加が実施される。
つまり、リリース済みのブランチと作業中のブランチは明確に分離して管理する必要があった。
チームメンバーが一つのシステムに対して、それぞれ個別に機能追加を担当する。
多機能な画面が複数ある複雑なシステムを複数の人数で分担して作業することで、短期間に構築する必要があった。
それぞれの作業はできるだけ独立性を高くしたかった。
二つの要件を同時に満たすのがGit-Flowだった。
とくに、一度リリースしたものをmasterブランチに保存しておいて、別ブランチで実装作業を進めるという手順が明確に記述されているという点を評価した。
神経使って管理するべきブランチが２本になることでオペレーションがややこしくなるよう見えるが、ホットフィックスブランチやリリースブランチが完了する際にmasterとdevelopの両方に行うマージを一動作で実行するので手順の煩雑さは影響しない。
使用するツールはSourceTreeを導入した。
コマンドラインにこだわる必要はない。
複数の人員で作業すると、必ずコンフリクトを起こす。
それはチームメンバーの技術レベルや習熟度などとは直接の関係はなく、だれでも起こしうる事故と解釈すべき。
その場合、修復作業をコマンドラインでやることは、不可能ではないがそれなりの学習コストがかかる。
同じ低い習熟度からスタートした場合、やはりGUIがあったほうがとっかかりを得やすい。
本格的な作業用リポジトリを作る前に練習用のリポジトリを作って、自分で一通りの操作を経験しておく。
リポジトリの内容はなんでもよく、例えば、ドキュメント用のリポジトリを一つ作成してみる。 そのリポジトリを複数のフォルダにチェックアウトし、それぞれを別の担当者に割り振ったという体で、フィーチャーブランチやリリースブランチ、ホットフィックスブランチの開始から完了までの動作をファイル修正を交えて実験する。
事前に操作をすることで、チームメンバーにレクチャーする際の要点を洗い出せる。
自分でやってみる過程において、作業工程をテキストに記録しておく。そしてそれをもとに公開用の手順書をテキストにする。
作成したテキストは、閲覧・修正が容易な形で配布する。
Githubの採用は当初から決定していたので、テキストはasciidoc形式で記述することにした。
Githubでasciidoc形式のテキストを使うことで、コミット・プッシュするだけでファイルの公開まで可能となる。
そのままGitの管理下としてバージョン管理されるので、詳細な変更履歴はあえて作る必要はない。
Gitを使う上でどの戦略を使うにしても、必ずアンチパターンがある。
これをチームメンバーに周知することが必要である。
テキストを用意するだけでは不十分なので、実際の操作をチームメンバーの目の前で、何度でも実演して見せる必要がある。
操作に困ったらいつでも声をかけるようにアナウンスをする。
チームメンバーにGitの経験が少なければ、Gitの概念そのものから学習する必要がある。
ところがこれが、けっこう難易度が高い。個人レベルの学習だと、目に見えない工数がどうしても必要となる。
一度のレクチャーやひとつのドキュメント公開ではきっと対応し切れない。
事前の想定できる範囲では、チームメンバーが実際に困ることのすべてをリストアップすることはできない。
困った時点で、その困った事柄を例題として、デモンストレーションをやって見せるのが、最終的にはもっとも対応工数が少なくなる。
実際にヘルプの要請がかかった場合はできる限り優先して対応する。
こまごまとした疑問にも丁寧に対応して行くと、そのうち、チームメンバーは、何かやらかす前に相談してくるようになる。
そうなったらしめたものである。
Git-Flow戦略の場合は、機能追加では master ブランチは手を付けない。
また、作業用である develop ブランチも、実作業は fearture ブランチを分岐して行うので直接編集することはない。
その上、ローカル開発環境にもリポジトリを作るので、プッシュしない限りは中央リポジトリには送信されない。
最悪の場合もでローカルのチェックアウトを削除すれば、全ての作業はなかったことになる。
つまり本格的に破局的な失敗をする前に何段階もセーフティーネットがある。
実演の際には、それらの使い方を説明する。
とにかくはじめて使う場合は不安がつきまとうので、ぶっ壊しても大丈夫という安心感を演出する。
/