LoginSignup
0
1

More than 1 year has passed since last update.

【備忘録】Git・Githubリポジトリ構成とメッセージ管理で参考にした情報

Posted at

はじめに

受託開発企業でシステムエンジニアをしている、@fusassyといいます。

受託開発プロジェクトにてチーム開発を進めるにあたり、バージョン管理でGit・Githubを採用することになり、Gitに関するルールを定めることになりました。Git・Githubについては、有益な記事が既に多くあります。プロジェクトで新たにルール策定をするにあたり、実際に参考にした記事・情報を備忘録として残します。

Gitリポジトリ構成管理

開発プロジェクトでは、開発・検証・本番の3種類のデプロイ環境先が用意されているとします。上記の記事におけるルールを少しアレンジした例を記します。ブランチを切る際に、「/」(スラッシュ) を使用することで、ブランチに階層構造を持たせることができます。master・develop・feature以外のブランチは、用途がハッキリ分かる名前にて命名し、適宜追加すれば良いと思います。

master:本番環境デプロイ用。リリースした時点のソースコードを管理するブランチ。
develop:開発環境デプロイ用。masterから派生。開発作業の主軸ブランチ。
feature:developから派生する、各機能を実装するためのブランチ。 「feature/xx」、「feature/yy」のように命名。
validation:検証環境デプロイ用。develop(またはhotfix)から派生。実装を完了した後、リリースに向けて検証を実施するブランチ。
hotfix:masterから派生。リリースされた後に発生したバグに対し、緊急対応するためのブランチ。「hotfix/zz」、「hotfix/xyz」のように命名。

コミットメッセージルール

コミットメッセージのルール案も色々あるのですが、個人的には以下の書き方が気に入っています。

コミットメッセージ雛形

<Prefix>:<Subject>
<空白行>
<Body>
<空白行>
<Footer>

コミットメッセージ例

Fix: 表記ルールに従って文言を修正する

表記ルールでは「続きをよむ」は「続きを読む」になっていた。
詳しくは、表記ルールの〇〇を参照。

#test
https://example.com/

Prefix

何をしたかを接頭辞で短く示す。Angular.js の開発者ガイドが情報源。
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type)

feat:新しい機能
fix:バグの修正
docs:ドキュメントのみの変更
style:空白、フォーマット、セミコロン追加など
refactor:仕様に影響がないコード改善(リファクタ)
perf:パフォーマンス向上関連
test:テスト関連
chore:ビルド、補助ツール、ライブラリ関連

Subject

何をしたか50文字未満の短い文章にします。チームメンバーが日本人開発者のみの場合、日本語表記がベターです。Subjectが長すぎることは、コミットの粒度が大きすぎる可能性が考えられます。(なお、GitHubでは50文字以上で警告、72文字以上で省略されるみたいです。)

Body

何故それをしたのか、追加・修正等が必要だった理由を文章にします。チームメンバーが日本人開発者のみの場合、日本語表記がベターです。コミットメッセージに修正内容を書きつつ、コード側でも同様の内容を充分に説明しておくことが望ましいです。(自己文書化(=コメントがなくてもコードの意図が分かる状態)がベスト。)

Footer

補足情報を記載します。チームメンバーが日本人開発者のみの場合、日本語表記がベターです。

Github Issue(Issues)の活用

受託開発プロジェクトにおいて上流工程の要件~設計フェーズでは、どうしてもExcelを多用する場面が多いため、Excel上での指摘・修正依頼が良いと思います。一方、実装フェーズにおける、コードレビュー後のプログラムの指摘や修正依頼については、Github Issueを利用する方が良いと思います。Markdownが利用できることも嬉しいです。ここではタイトルは簡潔に、コメントは丁寧を意識して書きます。もちろん、チームメンバーが日本人開発者のみの場合、日本語表記がベターです。

.gitignoreの定義内容

追跡対象にしたくないファイルを定義します。.gitignoreで指定するファイルはパターン化されますので、一度決めてしまえば類似プロジェクトで流用可能になります。

さいごに

以上、Git・Githubを利用する際のルールについて、情報を整理させていただきました。実際にアサインされた受託開発プロジェクトでも、これらのルールを基本として適用し、上手く機能しています。もし運用で新たに課題が発生した場合は、その解決施策についても随時、追記をしていきたいと思います。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1