Gitの運用ルール

リポジトリ

リポジトリの名前 snake_case

  • snake_case とする

  • 短くするように努める。長さの制限はしない。

文字コード UTF-8、改行コード LF

  • 文字コードは UTF-8 とする

  • 改行コードは LF とする

  • Windowsではチェックアウト、コミット時に自動的に改行コードをCRLFに変換しないようにする

    • 「Checkout as-is, commit as-is」とする

    • git config --global core.autocrlf false

リポジトリとファイルのサイズ

  • 1リポジトリは5GB以下に抑える

  • 1ファイルは100MB以下に抑える

  • 上記の制限が緩いサービスであれば遵守しなくてよい

Git LFS

  • リポジトリとファイルのサイズ では満たせない大きなサイズのファイルを扱う場合はGit LFSを使う

  • ただし、有償のGit LFSは原則使わない(理由)

    • ファイルサイズを小さくしたり、外部ストレージに置くことを検討する

ブランチ

  • 開発体制や期間に合わせて ブランチ戦略 のフローを選ぶ

  • 適宜、main ブランチの内容を git pull して作業ブランチに取り込む

  • 適宜、作業ブランチをリモートの作業ブランチに git push する

  • ブランチはマージコミット git merge --no-ff でマージする

    • GitHub: Create a merge commit

  • リリース時にはtagをつける

ブランチの名前 snake_case

  • snake_case とする

  • 名前の長さは制限しない

  • ブランチの種類 のプレフィックスをつける

  • チケット管理システムなどを使う場合は、チケット番号やIDをつける。例: feature/<ID> 。

  • 対象、ステージ、目的がわかるようにする

    • feature/file_dialog_inital

    • feature/file_dialog_multiple_files_support

ブランチの種類

main

  • 最新の開発ブランチ

  • 機能開発時はmainブランチから作業ブランチを作る

  • 常にリリース、デプロイ可能を求めない

feature/foo

  • 機能開発ブランチ

  • 機能の追加をする

fix/foo

  • 修正ブランチ

  • 既存の機能を修正する

rc/foo

  • リリース準備ブランチ(release candidate)

  • リリース予定の機能が含まれたもの

release

  • リリースブランチ

  • リリース準備ブランチではない。

  • mainブランチからマージする

hotfix/foo

  • 緊急修正を入れるためのブランチ

  • release からブランチを切る

  • 修正後に release と main にマージする

タグ

  • 納品、リリース対象のコミットにタグをつける

  • タグ名はプロジェクト毎に定義する

  • 特になければ日付にする YYMMDD。例: 20250304。

コミット

コミットの単位

  • 動くものをコミットすること

    • ビルドが通ること

    • 実行時、即クラッシュしないこと

  • 異なる目的の更新を一つのコミットに混ぜない

  • 保存、差分確認、ロールバック用として、main や release ブランチを除くブランチでの途中経過のコミットを歓迎する

コミットメッセージ

  • [ConventionalCommits] に合わせる

  • メッセージは日本語か英語にする。どちらを使っても、混ぜても構わない。

コミットメッセージのフォーマット

フォーマット

<type>(optional scope): <description>

[optional body]

例

update!(platform): サポートするプラットフォームをバージョンXX以降に更新

- 以前のプラットフォームはでは動作しない
type:

コミットメッセージのタイプ 。破壊的変更 [1] は ! をつける。

scope:

(オプション)対象領域。自由記述。

description:

概要

body:

(オプション)本文。箇条書きにする。

  • 1行50文字以内を目安にする [2]

  • 1行目は概要とする

  • 3行目以降を本文とする

コミットメッセージのタイプ

wip:

何かの作業の途中経過

update:

何かの更新、追加、改善

feat:

機能の追加

fix:

修正

docs:

ドキュメント

サブモジュール

参考文献

[ConventionalCommits]

Conventional Changelog. Conventional Commits. URL: https://www.conventionalcommits.org/ja/, (参照 2025-3-3).

[常松2023]

常松 祐一, 川口 恭伸, 松元 健. アジャイルプラクティスガイドブック チームで成果を出すための開発技術の実践知. 翔泳社, 2023.

[FutureGit]

フューチャー株式会社. Gitブランチフロー規約. Future Enterprise Arch Guidelines, URL: https://future-architect.github.io/arch-guidelines/documents/forGitBranch/git_branch_standards.html, (参照 2025-3-3).

[GizumoGit]

株式会社Gizumo. Gizumo開発チームで採用しているGitの運用ルールを紹介します. テックブログ, URL: https://gizumo-inc.jp/media/git-operation/, (参照 2025-3-3).

付録: ガイドラインの方針

要求、前提条件

  • VMTは少人数によるプロトタイプ開発が多い。スピードと効率を重視したい。

  • 対象はデスクトップアプリ(C++、Python、Unity、Unreal Engine)。Webやオンラインは別途考える。

  • ソロ開発なら直接mainにpushしたい

  • プロジェクト立ち上げ時はfeatureブランチを毎回切るのは手間。同一のブランチ上で色々な作業をしたい。場合によっては直接mainにpushしたい。

  • 複数バージョンの保守はしない

有償のGit LFSの使用は避けたい

画像、動画、バイナリ等の大容量になりがちなファイルはリポジトリの肥大化、git操作の低速化を招くので、Git LFSを使うことが推奨されている。 クラウドサービスの有償のGit LFSはストレージと通信量毎に追加費用が発生するものがある。 アクティブではないリポジトリにも定常的にコストが発生するので、有償Git LFSの使用は避けたい。 Git LFSを途中でやめてコストを調整する方法も考えられるが、Git LFSをやめる作業に手間がかかるため、管理面においても使用は避けたい。