Help us understand the problem. What is going on with this article?

複数人開発の際にはGitのワークフロー、GitFlowとGitHub Flowを導入すると便利です

More than 1 year has passed since last update.

GitFlowとGitHub Flowの違い

機能 GitFlow GitHub Flow
ブランチ名 master/develop/feature/hotfix/relase masterのみ制定
マージ方法 マージ PullRequestでマージ
リリース GitFlowリリースのリリース手順 masterブランチを常時リリース可能にしておく

git flowとgithub flowとは?その違いは? - Qiita

GitFlow vs GithubFlow - Qiita

GitFlow

ブランチの命名規則やコミットのタイミングについて規定されたものです。
git flowとgithub flowとは?その違いは? - Qiita

基本的なブランチのルール

developブランチ

このブランチを元に機能ブランチを作成する、ベースとなるブランチです。

GitHubであればDefault Branchdevelopにしておきます。

image.png

featureブランチ

機能開発を行うブランチです。featureという名前ですがバグ取りもこのブランチで行います。
Git(SourceTree)ではブランチ名をスラッシュで区切ることでグルーピングされるため、feature/... として作成します。

featureブランチの命名規則

featureブランチはスラッシュで区切ることができるため、ここに複数の情報を入れます。
具体的には

feature/201902/yousan/fix-admin-panel

といった形で作成しています。
feature/(yearmonth)/(username)/content
となっています。
その理由について述べます。

年月を入れる

featureの下に年月を入れています。
これはSourceTreeを使った場合のグルーピングやブランチ名でソートした場合、時間順でグルーピング、ソートすることができるからです。
開発が長くなってくるとブランチの数がそれなりに増えてきます。だいたい100個を超えたあたりから探すことが大変になってきます。
そこでこのようにスラッシュで区切ることで見通しを良くします。

image.png

GitHubのブランチはGitHub上で削除することができますが、Gitの実際の削除ではなく、GitHub上のソフトデリートです。
そのためGitコマンドなどで確認すると生きているブランチとして見えるため、「ちょっとこのブランチをチェックアウトして確認してほしい」とレビュー依頼を出す際など、探すことが困難になります。
こうしてグルーピングしておけば、少なくとも最新の月で絞り込めるため便利です。

Deleting and restoring branches in a pull request - GitHub Help

(削除について間違っているかもなのでその場合には教えてください)

ユーザ名を入れる

ブランチ名にユーザ名(GitHubやSlackのユーザ名と揃えています)を入れます。
こちらも上記の理由と同じく、見通しを良くするということがあります。
またその他にもブランチの持ち主を特定するために入れています。「このブランチって使われてないけど、消して良いのかな…。誰に聞けば良いんだ…」ということを防ぐことが出来ます。

またプルリクエストと同様に責任者を明らかにする、ということがあります。
「このブランチは俺のブランチだから、テストが通らなければ俺が直す責任がある」ということで、責任の所在をはっきりさせることができます。

新人エンジニアに覚えてもらいたいPullRequestの書き方 - Qiita

releaseブランチ

リリース時に利用します。
リリース用の調整を行ったり、ステージング環境へ反映させたりします。
CIサービスで自動デプロイする際の判定などにも使っています。

masterブランチ

ほぼreleaseブランチと同義ですが、各種バージョンが打たれているブランチです。
GitFlowのリリース機能で自動的にコミットしています。

hotfixは使っていません。

使っていません。

タグとバージョン

バージョン情報をつけています。
GitFlowのリリース機能でタグを付けた場合、GitHubで自動的にバージョン番号がついてリリースとして取り扱われます。

このバージョンをつけておくことで、システム側に自動的にバージョン番号を取ったりしています。便利!

システムを継続して開発する場合にはバージョン情報を自動で付けると良かったです - Qiita
https://qiita.com/yousan/items/cffa19f67f225097127d

ブランチを作成するときはdevelopから

普段のワークフローは下記のようになります。

  1. developからfeatureブランチを作成
  2. featureブランチで作業
  3. PR作成
  4. マージ

で、いくつかのfeatureをまとめてリリースを行います。

例外への許容

developへの直コミット

GitFlowでは基本的にdevelop直接コミットを許可していません。
GitHub(やBitBucket)ではdevelopへのコミット禁止ですとか、PRマージの際にレビューが完了していないとだめだとか、その他にも色々とルールを設けることが出来ます。

image.png

大きめの開発だとdevelopへの直コミは禁止しておくほうがよいですが、ですが僕のチームではある程度許容しています。
ただし単純なファイルの追加やGit以外での修正の反映などにとどめています。
コードの変更を許容することは規律が乱れてしまうので、手間と規律のトレードオフとなります。

ブランチの再利用

マージが済んだブランチは削除しています。
基本は1つのIssueに対して1つのブランチを作成し、マージされたら削除としています。
ただしGitHub側で削除されたブランチをそのままローカルで使うこともできます。
コミット、プッシュ、PRの作成を行うと連続してブランチは生き続けます。
ブランチ名との乖離(fix-adminという名前なのにフロントの修正をしている)がなければこれでもOKです。
また開けっ放しのブランチはdevelopとコンフリクトを起こしやすくなるので、コンフリクトが頻発するようであれば規制するなど、こちらも運用しながらある程度のルール化が必要となります。

名前

  • git-flow
  • Git flow
  • Git Flow
  • Gitflow
  • git flow

Gitflow Workflow | Atlassian Git Tutorial

yousan
自動化が好きです。CI/CDのCDが好きです。
https://floatingweed.com
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away