Skip to main content

脱初心者！ Git ワークフローを理解して開発効率アップ

git workflow

Git – チーム開発に必須のバージョン管理システムですが、その真価を発揮するにはワークフローの理解が欠かせません。 色々な人は Git の使い方を良く知っていますが、Git を仕事やワークフローに統合する方法を余り良く知らない人もいます。本記事では、Git をワークフローに組み込むことで、開発プロセスがどのように効率化され、チーム全体のパフォーマンスが向上するのかを解説します。Centralized Workflow から Forking Workflow まで、代表的な 9 つのワークフローの特徴を分かりやすく紹介します。それぞれのメリット・デメリット、そして最適なユースケースを理解することで、あなたのプロジェクトに最適なワークフローを選択し、開発をスムーズに進めましょう！

  1. Centralized Workflow
  2. Feature branching/GitHub Flow
  3. Trunk Based Flow
  4. Git Feature Flow
  5. Git Flow
  6. Enhanced Git Flow
  7. One Flow
  8. GitLab Flow
  9. Forking Workflow

分かりやすくするために、同じコンセプトを説明するに一つ以上の図を使った場合があります。

Centralized Workflow

説明：

集中化ワークフローではプロジェクトにおけるすべての変更の単一の入力箇所として中央リポジトリを使用します。デフォルトの開発用ブランチは main と呼ばれ、すべての変更がこのブランチにコミットされます。 集中化ワークフローでは main 以外のブランチは不要です。チームメンバー全員がひとつのブランチで作業し、変更を直接中央リポジトリにプッシュします。

メリット：

  1. SVN のような集中型バージョン管理システムから移行する小規模チームに最適。

デメリット：

  1. お互いのコードが邪魔になり (お互いの変更を上書きするように)、プロダクション環境にバグをい入れる可能性が高くて、複数のメンバいるチームでこのフローを使いにくい。

地図：


graph TD;
    A[Central Repository] -->|Clone| B1[Developer A's Local Repo]
    A -->|Clone| C1[Developer B's Local Repo]

    B1 -->|Make Changes| B2[Commit Changes]
    C1 -->|Make Changes| C2[Commit Changes]

    B2 -->|Push| A
    C2 -->|Push| A

    A -->|Pull| B1
    A -->|Pull| C1

Feature branching / GitHub Flow

説明：

すべての機能開発を main ブランチではなく専用のブランチで行う。main ブランチに壊れたコードは含まれない、いつもリリース出来るコードを含む。（master ブランチにあるものはすべてデプロイ可能だ） 開発者はメインブランチからフィーチャーブランチを作成し、変更が完了したらプルリクエストを使ってメインブランチにマージする。 mergeの後にフィーチャーブランチを消す。 開発者は絶対に直接にmainブランチにプッシュしない、いつもpull requestする。

メリット：

  1. すぐに理解することが出来る (一番分かりやすいワークフロー)
  2. main のコードベースに影響を与えることなく複数の開発者が別々のフィーチャー開発作業を行える
  3. CI/CD の為に適す
  4. プルリクエストの活用でブランチに関連した問題点を議論出来る
  5. よくリリースするプロジェクトに使える/に適す
  6. ウェブサイト開発のプロジェクトにように一つだけのバージョンが要るプロジェクトに適す
  7. merge conflict が少ない

デメリット：

  1. 主なブランチがmainしかないので、 異なるタスクを互いに分けて管理するのは少し難しくて、チームにとっては混乱した状況になる恐れがある
  2. リリースと開発ような環境専用のブランチがない、本番環境でバグが発生しやすく
  3. 同時に複数のバージョンをサポートする事が必要なら、このワークフローを使えない
  4. 複数のfeature branchの完了が（同時に）長く時間かかったら行ったら、mergeするのは難しくなる

地図：


地図 1

  Feature branching 
source: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow


地図 2

  Feature branching
source: https://www.optimizely.com/optimization-glossary/trunk-based-development/ 


地図 3


  GitHub Flow
source: https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy

Trunk Based Development

説明：

エンジニアは、小さな変更をより頻繁にメインのコードベースにマージし、長期間のフィーチャーブランチで作業するよりも、トランク(mainブランチ)のコピーで作業する。多くの場合、featureブランチには特徴の一部しか含まれないため、featureブランチは小さくなる。 featureブランチをmainブランチにmergeする前にfeatureブランチをよくテストする。

GitHub Flow と似ている、二つの違いさがある

  1. feature branchが完了するまで待たず、mainブランチにmergeする
  2. 小さいなチームの場合は小さなコード変更なら開発者は直接にmainブランチにプッシュ出来る

メリット：

  1. merge conflictが一番少ないワークフロー
  2. かりやすいワークフロー
  3. CI/CD の為に適す
  4. プルリクエストの活用でブランチに関連した問題点を議論出来る
  5. よくリリースするプロジェクトに使える/に適す
  6. ウェブサイト開発のプロジェクトにように一つだけのバージョンが要るプロジェクトに適す

デメリット：

  1. フィーチャーが完了ずmainにmergeするので、mainブランチにバグを入れ恐れがある
  2. フィーチャーが完了ずmainにmergeする為に、よくFeature Toggle/Flagを使られるけど、その為に経験を持っている開発者が必要
  3. 主なブランチがmainしかないので、 異なるタスクを互いに分けて管理するのは少し難しくて、チームにとっては混乱した状況になる恐れがある
  4. リリースと開発ような環境専用のブランチがない、本番環境でバグが発生しやすく
  5. 同時に複数のバージョンをサポートする事が必要なら、このワークフローを使えない 

地図： 


Trunk Based Development
source: https://www.optimizely.com/optimization-glossary/trunk-based-development/

Git Flow

説明：

mainとdevelopと言う 2 つの長期ブランチとさらにfeature、release、hotfix といった追加のブランチを特定の目的に使用する。ブランチの役割分担を明確にし、いつ、どのように相互作用するかを定義している。機能ブランチに加え、リリースの準備、メンテナンス、記録にも個々のブランチを使用する。

プロダクション環境のコードがmainブランチで保存される

メリット：

  1. 特別のreleaseブランチがあるので構造化されたリリースサイクルを持つプロジェクトに最適
  2. デプロイ前に機能の広範なテストを必要な場合に適す。
  3. プロジェクトをよく構造する (さまざまな種類のブランチがあるため、直感的に仕事を整理しやすい。)
  4. 同時にアプリケーションの複数のバージョンをサポート出来る

デメリット：

  1. プロジェクトによって開発プロセスやリリースサイクルを複雑にしすぎ、遅らせる恐れがある。
  2. (プロジェクトによって) CI/CD が難しい。
  3. 主なブランチがmainじゃなくて、developで、慣れるのが時間掛かる
  4. よく同じコードを二つのブランチにmergeする必要があるので、mergeを忘れ、間違いやすい(release と hot-fix ブランチの場合)
  5. Git History が分かりにくくなる
  6. アプリケーションが一つだけのバージョンがある場合は進めじゃない
  7. ほとんどの開発者や開発チームが実際に必要としているよりも複雑なのだ
  8. 複数のfeature branchの完了が（同時に）長く時間かかったら行ったら、mergeするのは難しくなる

地図：


地図 1

  Git Flow
source: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow 


地図 2 


Git Flow 
source: https://www.gitkraken.com/learn/git/git-flow 


地図 3


  Git Flow 
source: https://nvie.com/posts/a-successful-git-branching-model/

Enhanced Git Flow

説明：

Git Flowに似ている。develop、main、と言うブランチとfeatureブランチがある。 developブランチに蓄積されたものを放出するときは、厳密にはmainのスーパーセットだ。 開発はdevelopブランチで行われ、mainブランチはデプロイブランチです。developブランチの準備ができると、main ブランチの現在の先端が v1 などのアプリのバージョンとしてラベル付けされ、mainブランチのポインタがdevelopブランチを指すように変更されます。ホットフィックスがある場合はメインブランチに対して行われ、developブランチは続行されます。developブランチの準備ができると、メインブランチは v2 のタグで停止され、developブランチにマージされます（v3 になります）。 開発はdevelopブランチでして、リリースする時にdevelopブランチ名をmainに変わって、リリースバージョンをtagで書く。 featureブランチはdevelopにmerge`する

メリット：

  1. ブランチの種類が少ない (Git Flow より分かりやすい)
  2. リリースブランチと開発ブランチは別々
  3. GitHub Flow よりもっと整理され、構造化されている

デメリット：

  1. 余り人気がないワークフロー
  2. レポゾトリを運用する人は経験と技術が必要 

地図： 

Enhanced Git Flow
source: https://www.toptal.com/gitflow/enhanced-git-flow-explained 


Enhanced Git Flow 
source: https://www.toptal.com/gitflow/enhanced-git-flow-explained

Git Feature Flow

説明：

production、stage、deployment、featureと言うブランチがある。 featureはproductionブランチに基づう。

flowchart LR
    branch1(feature) -- merge --> branch2(development) -- merge --> branch3(stage) -- merge --> branch4(production)

流れじゃなくて、以下の通りです。

flowchart LR
    branch1(feature) -- merge --> branch2(development)
    branch1 -- merge --> branch3(stage)
    branch1 -- merge --> branch4(production)

メリット：

  1. 色々の環境のブランチがある

デメリット：

  1. 余り人気がない
  2. (他のワークフローと逆から)分かりにくい
  3. 不要なステップが多い(同じコードを各ブランチにmergeする)
  4. merge conflictが多い 

地図：


地図 1


gitGraph
    commit
    branch develop
    branch stage
    commit
    commit
    commit
    checkout main
    commit
    commit
    commit
    checkout stage
    commit
    commit
    commit
    checkout develop
    commit
    commit
    commit
    commit
    checkout main
    branch feature
    commit
    commit
    commit
    checkout main
    commit
    commit
    checkout stage
    merge feature
    checkout feature
    checkout develop
    merge feature
    checkout main
    merge feature



地図 2


  Git Feature Flow 
source: https://medium.com/dev-managers-handbook/git-feature-flow-125d28dfef1e

GitLab Flow

説明：

Gitlab Flowは 2 種類がある：Versioned Releaseと Continuous Release。

Versioned Release 三つのブランチがある:main、versionとfeature。 各リリースには、mainブランチをベースにしたリリースブランチを作成。featureブランチをmainブランチにmergeする。バグ修正は、リリースブランチにマージする前に、まずメインブランチにマージすべき。

Continuous Release mainとproduction、featureと言うブランチ(とpreproductionような環境ブランチ)がある。開発はmainブランチでし、リリースする時にmainブランチをproductionブランチにmergeする。（preproductionブランチがあったら、productionにmerge前に、preproductionにmergeする） main、productionとpreproductionブランチに直接にmergeしず、pull requestする。

flowchart LR
    b1(Master) -- merge --> b2(Pre-Production) -- merge --> b3(Production)

両方の種類でもmergeの後、featureブランチを消す。

メリット：

  1. フレキシブル
  2. （Versioned Release の場合は）アプリケーションの複数のバージョンをサポート出来る
  3. （ Continuous Release の場合は）アプリケーションの一つだけのバージョンもサポート出来る
  4. （ Continuous Release の場合は）CI/CD は導入出来る
  5. Git Flow と Enhanced Git Flow より分かりやすい
  6. GitHub Flow よりもっと整理され、構造化されている

デメリット：

  1. 一番分かりやすいワークフローじゃない (GitHub Flow が一番分かりやすい)
  2. 一番整理され、構造化されているワークフローじゃない
  3. Merge Conflict が起こる恐れがある

Versioned Release の地図:


Gitlab Flow Versioned release 
source: https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy 


Continuous Release の地図：


Gitlab Flow
source: https://github.com/jadsonjs/gitlab-flow 


Gitlab Flow
source: https://github.com/jadsonjs/gitlab-flow 


Gitlab Flow 
source: https://github.com/jadsonjs/gitlab-flow 


Gitlab Flow 
source: https://github.com/jadsonjs/gitlab-flow 


地図 2

  Gitlab Flow 
source: https://github.com/jadsonjs/gitlab-flow

One Flow

説明：

Git Flowに似ているけど、違いさはdevelopブランチがない、開発はmainブランチでする。 mainブランチにmergeした後にmergeしたブランチを消す(featureとかreleaseとかhot-fix)

メリット：

  1. Git Flow より分かりやすい
  2. GitHub Flow より組織的

デメリット：

  1. CI/CD に余り最適じゃない
  2. merge conflict がよく起こる恐れがある

地図：


gitGraph
    commit
    commit
    commit
    branch feature_a
    checkout feature_a
    commit
    checkout main
    commit
    branch release1
    commit
    commit
    commit id: "v1.0"
    checkout main
    merge release1
    checkout feature_a
    commit
    checkout main
    merge feature_a
    commit

Forking Workflow

説明：

このワークフローを他のワークフロー一緒に使うはずです。 外部の貢献者がメインのリポジトリに直接アクセスせずに作業できるようにするものである。貢献者は、メインリポジトリに直接アクセスすることなく作業を行うことができます。開発者はメインリポジトリのフォーク（個人的なコピー）を作成し、そこに変更を加えます。そこに変更を加えます。そして、その変更をメインリポジトリに統合するためにマージリクエストを提出します。メインリポジトリに統合します。 単一のサーバーサイドリポジトリを「中央」のコードベースとして使う代わりに、すべての開発者に独自のサーバーサイドリポジトリを提供します。つまり、各開発者はひとつではなくふたつの Git リポジトリを持つことになります。プライベートなローカルリポジトリと、パブリックなサーバーサイドリポジトリです。フォークワークフローは、公開オープンソースプロジェクトでよく見られます。

このワークフローを他のワークフローと一緒に使える

メリット：

  1. オープンソースプロジェクトに最適

デメリット：

  1. オープンソースプロジェクトじゃない場合は、プロジェクトに不要なステップをもたらす。

結論

全ての条件を満たすワークフローがない、一番良いワークフローもないです。どのワークフローを使うのはプロジェクトによって、チームのよって、多くの場合は好みによってです。上のワークフローは決まりじゃないので、色々な会社は自分の理解、条件と好みによって色々な修正/調整し、使っています。

私の意見では GitLab Flow が良いです。理由は環境ブランチがあり、余り複雑じゃないのでです。

役に立つリンク

Centralized Workflow (集中化ワークフロー):

  1. https://www.atlassian.com/ja/git/tutorials/comparing-workflows
  2. https://www.atlassian.com/git/tutorials/comparing-workflows#centralized-workflow

Trunk Based Flow:

  1. https://www.optimizely.com/optimization-glossary/trunk-based-development/
  2. https://www.optimizely.com/optimization-glossary/feature-flags/
  3. https://www.optimizely.com/optimization-glossary/feature-toggle/
  4. https://martinfowler.com/articles/feature-toggles.html
  5. https://trunkbaseddevelopment.com/
  6. https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development

Feature branching/GitHub Flow:

  1. https://docs.github.com/en/get-started/quickstart/github-flow
  2. https://www.atlassian.com/ja/git/tutorials/comparing-workflows/feature-branch-workflow
  3. https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
  4. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
  5. https://scottchacon.com/2011/08/31/github-flow.html

Git Flow:

  1. https://www.atlassian.com/ja/git/tutorials/comparing-workflows/gitflow-workflow
  2. https://nvie.com/posts/a-successful-git-branching-model/
  3. https://www.gitkraken.com/learn/git/git-flow

Enhanced Git Flow:

  1. https://www.toptal.com/gitflow/enhanced-git-flow-explained

Git Feature Flow:

  1. https://medium.com/dev-managers-handbook/git-feature-flow-125d28dfef1e

GitLab Flow:

  1. https://github.com/jadsonjs/gitlab-flow
  2. https://microfluidics.utoronto.ca/gitlab/help/topics/gitlab_flow.md
  3. https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
  4. https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/

One Flow:

  1. https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow

Forking Workflow:

  1. https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow

General:

  1. https://nira.com/git-flow-vs-github-flow/
  2. https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy
  3. https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
  4. https://about.gitlab.com/topics/version-control/what-is-git-workflow/
Labels:

Comments

Post a Comment

Popular posts from this blog

From Generic to Genius: Fine-tuning LLMs for Superior Accuracy in Snowflake

TL;DR: Cortex Fine-tuning is a fully managed service that lets you fine-tune popular LLMs using your data, all within Snowflake. While large language models (LLMs) are revolutionizing various fields, their "out-of-the-box" capabilities might not always align perfectly with your specific needs. This is where the power of fine-tuning comes into play. As it will be explained in this article, this feature empowers you to take a base LLM and customize it to excel in your particular domain. Here's the brief summary of why you might want to leverage Snowflake's fine-tuning capabilities: Unlocking Domain Expertise : Pre-trained LLMs are trained on massive, general datasets. Fine-tuning allows you to build upon this foundation and train the LLM further using data specific to your field, such as legal documents, medical records, or financial data. This empowers the LLM to understand complex terminology and patterns unique to your domain, leading to more accurate a...
Post a Comment
Read more

How Wendy’s Successfully Penetrated the Japanese Market After Long Struggles

Wendy’s had long struggled to penetrate the Japanese market. Initially the Daiei Group tried to bring Wendy’s to Japan but failed. The next owner of Wendy’s’ Japanese franchise, Zensho Holdings Co. also failed miserably. However, Japanese-American entrepreneur Ernest M. Higa seems to have managed to do the task. This article will discuss the challenges Wendy’s faced when entering the Japanese market, how Ernie Higa addressed those challenges, macro environmental factors that impacted the success of the brand in Japan, future threats the Japanese fast food market is facing , and potential solutions. The prior challenges that Wendy’s faced when they entered the Japanese market There is no one-size-fits-all formula in business, especially when Japan is involved in the conversation. According to Japanese-American entrepreneur Ernie Higa, even if a company has a good product and good pricing, penetrating the Japanese market is more difficult compared to the US’s market. Foreign e...
Post a Comment
Read more