git,GitLabを1年半使った現状

こんにちは、河野です。

一昨年にgitについての社内勉強会を行い、その内容を gitの勉強会「はじめようgit」を行いましたにてまとめました。それから1年半ほど経ったので現状をまとめようと思います。

ワークフロー

git flow、GitHubフローを参考に始めましたが、現在は develop,master,各feature以外に、stagingブランチを設けるようにしています。

自分がいるチームは、SIのプロジェクトが中心なので頻繁にリリースすることはありません。ですので、

各featureブランチで機能を開発→developへマージ
社内のテストはdevelopを中心に行う→テストが一巡したらstagingへマージ
お客様確認用のステージング環境へはstagingブランチを使用
ステージング環境でのテストも終わったらmasterへマージ
最新のmasterをリリースし、タグを打つ

という流れです。

最初の頃は、developブランチをステージング環境でも利用してテストなど行っていました。それでも問題なかったのですが、マイルストーン的な意味合いでstagingブランチを設けてみました。

そんなわけで、現在では「GitLab flowの環境ブランチ」と似たようなフローになっています。
cf: 【翻訳】GitLab flowから学ぶワークフローの実践 | POSTD

featureブランチの名前

featureブランチの名前は、タスクの番号（管理はRedmineかGitLab）を付けるようにしていて、

issue-NNN-FEATURE-NAME

1	issue-NNN-FEATURE-NAME

というフォーマットにしています。NNNがチケットの番号です。FEATURE-NAMEは必須ではありません。英訳に悩むこともあって、その時間がもったいないかなと思ったので…。

コードレビュー

一番影響があったのがコードレビューだと思います。

svnで管理していたときは「コードレビューをしよう！」という努力目標でした。

Gitlabになって、

マージリクエスト
コードレビュー
マージ

というプロセスが明確になりました。

可視化されたことで、コードレビューの負荷が結構あるね、というのも認識されましたし、開発プロセスの改善につながっているのを感じています。

コミットの粒度・頻度

理想としては、適度に小さいコミットを頻繁に行うというのを考えていますが、実際にはそこまではできていないです。

たまに、ジャイアントコミットをpushされることもあります。svn時代の習慣が抜けないのだろうなぁと思うのですが、その度に「gitはそうじゃないんだよ！」と説明しています。

履歴の改変

基本的に履歴の改変は行わないという方針にしています。

OSSにコントリビュートするような場合には適切に履歴を作ることが必要かも知れませんが、社内のプロジェクトでそれをやる必要性を感じませんでした。
また、gitに慣れるまでは履歴の改変には手を出すべきではないなと思っています。

ですので、導入当初は履歴が改変できることも、rebaseの説明もあえてしませんでした。

たまにコミットすべきブランチを間違えた、ということも起きたりするのですが、それはそれとして割り切ってそのまま作業を進めるようにしています。そこで履歴を改変して正しい姿にすることよりは、そういうミスを起こさないように作業者の環境を見直すように促したりしています。

GitLabのバージョンアップ

最近では、GitLab CE Omnibus packageというのがあり、インストールやアップデートは簡単に行ってくれます（Chefが利用されているようです）。が、導入当時はCentOSも公式サポートはなく、パッケージもなかったので手作業で導入しました。また、当時はMySQLが標準DBだったのですが、今ではPostgreSQLが標準DBになっています。

そんなわけで、今でもアップデート作業は手順書を参考にしながら手作業でやっていて、なかなかツラいところです。MySQLからPostgreSQLに移行できればOmnibus packageでのアップデートができるようになるとは思うのですが、DBの移行はどうしても慎重になってしまい、実現できていません。

その他の感想

大きなバイナリファイルどうするの

gitでは、大きなバイナリファイルの扱いに困りますね。

git-annexや、git-lfsが利用できそうですが、今のところ問題に直面していないのも正直なところです。

導入の混乱など無かったか

もともと社内でもファーストケースではないし、個人的には触っている人もそこそこいたので、gitに移行するにあたって、そこまで大きな混乱はなかったのではないかなーというのが正直な感想です。

もちろん、プッシュが上手く行かないとか、気づいたら違うブランチにコミットしていたとか、そういうことはありましたが、そこに目くじらを立ててもしょうが無いのですよね。まずはとにかく慣れてもらうことが重要だと思っていたので、「今度から気をつけましょう」という感じで流してきました。

コードレビューが集中してしまう

これは良くある問題なんだと思いますが、レビューする人が特定の人になってしまうことがあり、レビューの負荷が高くなりすぎることがあります。

雑にレビューしても意味が無いし、またレビュアーになって他人のコードを見る作業の教育的側面もありますので、上手くメンバーをローテーションできるようにしようと思っているところです。

gitに変えて良かったか

一番良かったのは、コードレビューが可視化されたことです。またそれに関連して、開発プロセスを見直すきっかけになったのも良かったと思います。GitLabでのWeb Hooksを起点として通知を行ったり、CIのジョブを開始したりすることも容易になったので、連携がスムーズになった気がします。

以上、現状のまとめでした。