私たちの開発チームは 4 人で、最近 Git に移行しました。ブランチとマージのワークフローに関するベスト プラクティスを学びたいと思っています。
私たちは Git Flow の軽量版を使用しています。開発、ステージング、マスター ブランチがあり、これらはすべて互いに直線的です。
- ステージングはマスターから分岐しています
- dev は staging から分岐しています
さらに、機能ブランチとホットフィックス ブランチを使用して、新しい機能の開発やバグの修正を行います。
以下の質問があります:
- 機能ブランチは dev から分岐するべきでしょうか、それとも master から分岐するべきでしょうか?
- 機能ブランチの準備ができたら、機能ブランチを dev にマージしてから dev を staging にマージするべきでしょうか、それとも機能ブランチを staging にマージしてから機能ブランチを master にマージするべきでしょうか?
開発段階にステージングとマスターにマージしたくないものがあるかもしれないので、マスターから分岐して機能ブランチをマージする必要があると思います。
あなたの意見は？ベストプラクティスは何ですか？
ベストアンサー1
Git Flow は優れたブランチ モデルですが、あなたが尋ねている質問は、より大きな問題の兆候です。つまり、Git Flow は、消費者向け Web 製品に取り組んでいる小規模チームには重すぎるのです (消費者向け Web 製品に取り組んでいると想定していますが、原子力発電所の制御室をコーディングしている場合は無視してください)。
非常にシンプルなブランチ モデルを使用した継続的デプロイメント (CD) を検討することをお勧めします。
最近は CD のセットアップがとても簡単になりました。
- 使用トラヴィス、コードシップ、Jenkins または同様のシステムを使用して、コードベースのすべてのブランチにプッシュされたすべてのコミットで完全なビルドとテストスイートを実行します。
- テストに合格したマスターへのすべてのコミットを本番環境にデプロイするように Travis/Codeship/Jenkins を設定します。
master新しい機能ごとに新しいブランチを作成します。- 新しい機能をコーディングし、ブランチでテストします。
- 機能ブランチを にマージし
master、それがライブになるのを確認します。
これに対しては多くの反対意見がありますが、そのすべてをまとめると「でも、バグが入ったらどうするの?」となります。答えは「修正すればいいのです!」です。テストを書き、実稼働サイトを監視し、コードレビューを行い、ペアプログラミングを実践し、機能フラグを使用し、機能を小さく保つと、CD から得られるメリットは、時折発生する問題よりもずっと大きなものになります。
ぜひ試してみてください。そうすれば、本当に重要なこと、つまり素晴らしい製品を作ることに集中できるようになります。信じられないなら、これを見てみて下さい。Githubからの素晴らしいプレゼンテーション。