Gitのブランチの役割を考える | フューチャー技術ブログ

Gitのブランチ戦略にはいくつかあります。 Gitフロー GitHubフロー GitLabフロー チームの戦略を考えるときにどれかを参考にしつつカスタマイズするときにいろいろ不都合が生じてしてきて複雑になってしまうことってありますよね？ 社内でブランチの管理の議論をする中で、ブランチの役割を明確にした上で、どのブランチがどのような役割を持っているのかを明確にした方が混乱が少なくなるのではないか？ というのを考えていました。 特に、プロジェクトごとに同じ名前でも役割が違うなー、というのとかもあり、ブランチ名＝役割ではなく、ブランチの上位概念として役割を考えて、それを実際のブランチとの対応づけを行う必要があるのではないかな、と。 CI/CDと組み合わされることで、releaseブランチ==ステージング環境となってしまい、ステージング環境を使いたいリリース前のブランチと、ホットフィックスの検証の

[perl-o-pal]

環境別の設定をgitに入れたくないけど、入れざるを得ないよなあと毎回悩む。

[santhiagoman]

ブランチ

[mohri]

“今時のGitは基本分散リポジトリとして使うのではなくて、GitHubやGitLab上の中央集権で使うということで、それらのサービスの提供するブランチ保護機能も考慮した作戦立案が必要不可欠でしょう”

[als_uz]

役割での整理は個人的には新鮮。参考になる

[lanius]

作業、集積、スナップショット、環境で分類。

[l__LINE__l]

main を今動いているコード、developが次のリリース対象、開発や修正は全てfeature としていた。 release はデプロイのために使う感じ

[hirorock]

ブランチ戦略

[zex5yo]

[CI/CD]