Git の慣習

技術とアーキテクチャ で解説されている通り、Wantedly のサービスは、各々が独自のリリース・サイクルを持つ多数のソフトウェア・コンポーネントの組み合わせによって動作しています。 それぞれにコンポーネントに対して 1 つの repository を管理しています。

一般の慣習

このセクションでは技術領域に関わらない慣習を解説します。

master branch の利用

一般には main branch を default の branch として運用することが多くなって来ていますが、 Wantedly このでは数多くの repository の CI 設定や自動化フローにおいて master をハードコードして利用してきました。 短期間での移行が難しいため、 2022 年 1 月現在では master branch を default で利用している repository が多数派です。

branch 名に username を入れる

GitHub Flow を採用している背景から、殆どの場合一つの branch と一人の開発者がひも付きます。 不要なコンフリクトを避けるために branch は <github-username>/<feature-name> のように命名します。

Pull Request 重視

Wantedly では伝統的に Pull Request の description をコミットメッセージよりも重視します。 コミットメッセージで深く悩まずにコミットを重ねて早めに Pull Request を作ると良いでしょう。 Pull Request の書き方は コードレビュー を参照してください。

マイクロサービス開発における Git

このセクションではマイクロサービスの repository 特有の慣習について解説します。 バックエンド及びフロントエンドのコンポーネントがこれに該当し、 モバイルアプリ / 社内ライブラリ / 社内ツールなどは必ずしもこのセクションで解説する慣習をとっていないことがあります。

Kubernetes / Docker との対応

マイクロサービスは下の性質を持ちます。

• Kubernetes クラスタに Deploy される

• 1 つの GitHub repository をもつ

• 1 つの Kubernetes namespace (repository 名と同名)をもつ

• 1 つの Docker image をもつ

このため一つの名前で、GitHub repository, Kubernetes namespace, 一つの microservice など複数のものを指すことがありますが、 上記の対応関係のために混乱することは殆どありません。

Kubernetes 概要および Wantedly における運用については プロダクト開発のための Kubernetes 入門 を参照してください。

GitHub Flow の採用

バックエンド及びフロントエンドでは GitHub Flow を採用しています。 したがって下のようなスタイルの開発になっています。

• master branch から topic branch を切る

• master branch に対して pull request を作る

• master branch が更新されるたびに本番環境に反映される

これを維持するために commit を push するたびに Docker image が作成され、master branch の更新に合わせて自動で本番環境が更新されるようになっています。

技術的な詳細は リリース・デプロイ戦略を支える技術 を参照してください。