Git の慣習

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

一般の慣習

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

main branch の利用

2025年12月から、ウォンテッドリーではデフォルトブランチ名として main の利用を推奨する方針となりました。それ以前はほとんどのリポジトリで master を使っていました。

デフォルト設定として以下を推奨します。

# git init のデフォルトを変更 (Git 3.0 以降では不要になる予定)
git config --global init.defaultBranch main

インフラ側ではブランチ名の変更について基本的な対応はできています。2025年12月時点で、いくつかのリポジトリはすでに main branch で問題なく運用が続けられています。

2025年12月時点では master branch のままになっているリポジトリが多数派です。これらの既存リポジトリについても、 main への変更を漸進的に行う予定です。

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 の更新に合わせて自動で本番環境が更新されるようになっています。

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