Gitflow

2022年現在はレガシー扱いされている

参考

本家

2010年に書かれた記事

複数のbranchを扱う

main branch

リリースを管理するbranch

リリースのタイミングでdevelopをmainにmergeする

この時にsquashする

1つ1つのcommitにtagを打って、productのverisonの管理をする

develop branch

開発時の主軸になるもの

開発時の全てのcommitがここに含まれる

squasしない

featureはここにmergeする

feature branch

開発時のサブ軸になるもの

個々人が、個々の機能を作る時にdevelopから切る

開発が終わったらdevelopにmergeする

release branch

releaseのタイミングでdevelopから切る

releaseに向けた、バグ修正、docs作成、その他のreleaseに伴うタスクを行う

ここから更にfeatureを着ることはない

準備ができたらmergeに入れてリリース

リリース後にdevelopにも入れる

その後、このbranchを削除する

hotfix branch

masterに対してのバグ修正を行う

masterから切って、masterとdevelopにmergeする

masterから切るfeatureのようなもの

https://gyazo.com/3baa709a2c9ffef518c6134e7fdb5a8a https://www.atlassian.com/ja/git/tutorials/comparing-workflows/gitflow-workflow

https://gyazo.com/d637e39cc59aa02bf5989828746c6542

アンチ

どこが問題なのか

どこに複雑性があるのか

どう解決するのか

とかを理解したい

複数人で同時に開発することと、リリースタイミングの問題とかか

deployの自動化はどうやって行うのか

例えばmasterにmergeしたら自動リリースみたいなやつは↓この方法ではどうやるのか

用語が多くて何を言っているか理解できない

develop

主軸、全ての履歴を含む

メンテブランチ

hotfix branchのこと

統合ブランチ

?

topic

hotfixとfeature

この2つは同じ立ち位置なので

next

図がほしい