共同開発のすすめ

最後に、統制の効いた共同開発においてはコミットメッセージやブランチ名、その他の Git や Gitea の扱いにどんなルールが定められているのか、よくある例をいくつか紹介します。

この章の内容の実践が個人開発やハッカソンの共同開発において強制されることは普通ありません。まずはそんなことを気にせず積極的に開発に参加するのがよいです。その上で、責任ある開発の現場でどんなルールが採用されているのかについて少しでも知っておくと、その知識が普段の開発にも何か示唆を与えてくれるかも知れません。

接頭辞

コミットメッセージやブランチ名の頭に決まった種類の接頭辞をつけることで、そのコミットやブランチの意図の分類を明確にすることが出来ます。たとえば以下がよく使われます。

接頭辞	一般的な意味合い
feat	新機能の追加
fix	既存の機能の問題修正
hotfix	緊急の問題修正
style	コードのスタイル変更やフォーマット
docs	ドキュメントの変更
chore	コードやドキュメントに影響しない作業
refactor	リファクタリング（コードの整頓）

コミットメッセージに接頭辞をつける場合は feat: 行った操作 のように、ブランチ名に接頭辞をつける場合は feat/行う予定の変更 のように書くことが一般的です。traQ フロントエンドリポジトリの Branches と Commits で実例を確認してみましょう。

ブランチ名に含まれるスラッシュ

Git ではブランチ名にスラッシュ / を含めることができます。このスラッシュはディレクトリのパスに含まれる / に似た振る舞いを示し、たとえばすでに feat/ーーを追加 という名のブランチが存在する場合は新たに feat という名前のブランチを作ることが許されなくなります。

ブランチ戦略

リポジトリ の章で GitHub Flow というものに触れました。これは、リポジトリでの開発を効率的・安全に進めるために提唱されたブランチの役割分けの方法（ブランチ戦略）の最もシンプルな例のひとつです。

上図は代表的なブランチ戦略それぞれにおける各ブランチの呼び名と関係の図解です。上図に登場する feature ブランチは、feat『新機能の追加』に限らず幅広い種類の『ひとまとまりの変更』を意味するものと考えていただいて大丈夫です。

GitHub Flow では feature を main にマージすることで変更が即座に本番環境に反映されるので、頻繁に本番用のブランチが更新される、迅速な開発を可能にする戦略です。traP ではほとんどのプロダクトの開発に GitHub Flow が採用されていますが、ある程度長期的・保守的な共同開発では feature がマージされるブランチと本番用のブランチを分離する Git Flow や GitLab Flow が好まれることがあります。

トランクベース開発

リポジトリ の章で述べた通り、共同開発で main に直接コミットしていこうとすると複数の部分の開発を同時に進めることが極端に難しくなります。それゆえこの方法はあくまで個人開発向きであり、共同開発に採用するのは『実用的ではない』としました。しかし、実は共同開発でこのようなブランチ運用をしている場合もあるにはあり『トランクベース開発』と呼ばれています。小規模なチーム全体である狭い範囲の開発をハイスピードで進めるために限定的にとられる手法です。