Git-Flowとは

💡
現在主にAltiveで使用しているフローはこちら

Overview

  • 単語の区切りはハイフン とする
  • , は常に存在するブランチ、その他はプルリクエストを介したマージが完了したら削除する。(GitHubの設定で自動削除可能)
  • , ブランチは直コミット禁止。必ずプルリクエストを介してマージする。

プルリクエストのマージについて

プルリクエストのマージは以下2種類のマージを使い分ける。

Create a merge commit

ブランチや ブランチは、複数のブランチ( , )にマージする必要があり、この時 を使用してしまうと、同一のコミットとみなされず次回コンフリクトが発生してしまう。必ずこちらのマージ方法を使用すること。

Squash and merge

ブランチは、 ブランチ、または ブランチ同士でしかマージしない。
ブランチ内での細かいコミット履歴は不要なことが多く、 でマージすると無駄にコミット履歴が嵩むことになる。
そこで を使用すると、マージがただ1つのコミットで表現される。(=プルリクエスト単位のコミット履歴となる)
や、Tag同士 ( )でコミット差分を見るときも、コミット履歴がプルリクエストタイトルで並んでいて分かりやすい。

基幹ブランチ

main

リリース単位の開発成果がこのブランチにマージされる。
, ブランチのマージ対象となる。
リリースされたら、マージコミットにタグを打つ e.g.:  

develop(開発ベースブランチ)

ベースとなる開発ブランチ。
, ブランチのマージ対象となる。

トピックブランチ

feature(機能追加・改善)

e.g.: 
機能ごとに  ブランチを作成し、プルリクエストを介して  へ していく。
💡
を使用することで、不要な委細コミットを ブランチに表示させなくて済む。

hotfix(障害対応)

e.g.: 
リリース後に、早急な対応が求められる不具合が発生した場合は、  ブランチから  ブランチを作成する。
障害対応を行い、バージョン番号とビルド番号を更新してから  と  へする。

release(リリース対応)

e.g.: 
リリース(テスト配信を含む)を行う際に  から作成する。
バージョン番号とビルド番号を更新してプルリクエストを作成、  と  へと する。

参考リンク