小規模チーム向けのGitワークフロー
小さなチームで実装するgitワークフローに取り組んでいます。ワークフローの中核となるアイデア：
- すべてのチームメンバーが書き込み可能な共有プロジェクトマスターがあります
- すべての開発は機能ブランチでのみ行われます
- 機能ブランチは、ブランチ作成者以外のチームメンバーによってコードレビューされます
- 機能ブランチは最終的に共有マスターにマージされ、サイクルが再び始まります
この記事では、このサイクルの手順について詳しく説明しています。
https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md
これは理にかなっていますか、それとも何か不足していますか？
gitフロー分岐モデル が好きです。ほとんどの場合、masterブランチはそのままにされ、リリースのみが含まれます。開発ブランチは常に安定している必要があり、機能ブランチは壊れる可能性があります。
また、これを継続的インテグレーションと組み合わせることができます。もちろん、物事が機能していて壊れていないことを確信している場合にのみ、開発にマージする必要があります。
継続的統合というトピックが欠けていると思います。すべての開発設定の一部である必要があります。
機能ブランチを使用すると、継続的に統合するのではなく、機能が完了した後にのみ問題が発生します。
分岐した機能が短命である場合、これは許容できるかもしれませんが、明らかに考慮すべきものです。
別の代替策は、各機能ブランチのCIビルドをセットアップすることです。これは確かに役立ちますが、統合ではありません。これは、機能Aにも機能Bにも現れないが、機能AとBを統合した最初のバグを見つけたときに明らかになります。
3番目の方法は、CIビルドの一部の統合ブランチにマージすることです。これは本当の統合であり、作業がいくらか分離されている場合、実際にはgitでかなりうまく機能しますが、ビルド中にマージ競合が発生し、ビルドが失敗します。