Gitでのベストプラクティスの分岐とマージ
開発チームは4人で、最近Gitに移行しました。分岐とマージを使用したワークフローに関するベストプラクティスを学びたい。
Git Flowの軽量バージョンを使用しています。 dev、staging、masterブランチがあり、これらはすべて互いに線形です。
- ステージングはマスターから分岐します
- devはステージングから分岐しています
その上で、機能と修正プログラムのブランチを使用して、新しい機能を実行し、バグを修正します。
次の質問があります。
- フィーチャブランチを開発者またはマスターからブランチする必要がありますか？
- 機能ブランチの準備ができたら、機能ブランチをdevにマージしてからdevをステージングにマージするか、機能ブランチをステージングにマージしてから機能ブランチをmasterにマージする必要がありますか？
ステージングとマスターにマージしたくないものがdevにある可能性があるため、マスターからブランチして機能ブランチをマージする必要があると思います。
あなたの意見は何ですか？ベストプラクティスは何ですか？
Git Flow と呼ばれるワークフローに落ち着きましたが、devから機能を分岐する代わりに、現在のリリースから機能を分岐します。これにより、異なる速度で別々の問題に取り組むことができます。 QAで成功した場合、リリースに進みます。
ブランチと展開について：
- devブランチは、テストサーバーに自動的にデプロイされます。
- 現在のリリースブランチは、ステージングサーバーに自動的に展開されます。
- masterブランチは、リリースマスターによってライブサーバーに手動でデプロイされます。
ワークフローは次のとおりです。
- 各リリース/スプリントの最初に、masterからリリースブランチを作成します。 release/2015-may。
- devからrelease/2015-mayブランチを作成します
- 新機能の開発、リリースからの分岐、feature/
ISSUE_NUMBER。 - 機能に取り組みます。
- テストの準備ができたら、devにマージします。
- 受け入れられた場合は、現在のリリースブランチにマージします。
- 受け入れられない場合は、手順4に進みます。
- リリースの準備ができたら、masterにマージします
リリースがライブにデプロイされ、重大なバグが発見された後、マスターからホットフィックスブランチをブランチします（例：ホットフィックス/ ISSUE_NUMBER）、それをマスターにマージし、再度デプロイします。
これは常に、あなたがどのように働きたいかとチームの合意に依存します。そうは言った。
- 機能はdevブランチから始まり、独自のブランチに入ります。マスターブランチからは、 hotfixes のみをブランチする必要があります。なぜなら、マスターブランチは常にあなたの安定したバージョンでなければならないからです。ソフトウェア。
- feature branch が完了したら、それを dev にマージし、ある時点で次のリリースをdevからブランチする必要があります（いくつかの機能）を新しい 'release/*'ブランチに追加します。これは、安定して十分にテストされた後、マスターにマージされます。
アトラシアンのページには、このワークフローの非常に素晴らしい説明があります
この種のワークフローの全体的なアイデアは、安定したバージョンブランチを用意することです。このブランチでは、バグがまだ安定しており、新しい機能やリファクタリングが気付かずにスリップしないという十分な自信を持って作業する必要がある場合、すぐに作業してバグを修正できます。
また、独自のブランチで開発される新しい機能ごとに、他の機能からのノイズなしで分離と自由を確保します。最後に、機能をdevブランチにマージし、そこから次のリリースのmasterブランチにマージします。
私がお勧めする唯一のことは、別の機能がdevにマージされるたびにdevブランチの上に機能ブランチをリベースする方法を学び、マージ時間の競合を解決することを避けますが、あなたが何を知っている機能ブランチで単独で変更があります。
Git Flowは優れた分岐モデルですが、あなたが尋ねている質問はより大きな問題の症状です：Git Flowは消費者Web製品に取り組んでいる小さなチームには重すぎます（私はあなたが消費者Webに取り組んでいると仮定しています原子力発電所の制御室をコーディングしている場合は無視してください）。
非常に単純な分岐モデルで継続的展開（CD）を検討することをお勧めします。
最近のCDのセットアップは非常に簡単です。
- Travis 、 CodeShip 、Jenkinsまたは同様のシステムを使用して、コードベースのすべてのブランチにプッシュされるすべてのコミットで完全なビルドおよびテストスイートを実行します
- Travis/Codeship/Jenkinsをセットアップして、テストに合格したマスターへのすべてのコミットを運用環境に展開します。
- 新しい機能ごとに
masterから新しいブランチを作成します。 - 新しい機能をコーディングし、ブランチでテストします。
- 機能ブランチを
masterにマージし、稼働するのを確認します。
これには多くの一般的な反対意見があり、それらはすべて「しかしバグを導入したらどうなるか！」と要約できます。答えは「修正します！」です。テストを作成する場合、本番サイトを監視する場合、コードレビューを行う場合、ペアプログラミングを実践する場合、機能フラグを使用する場合、および機能を小さく保つ場合、CDから得られる利点が時折発生する問題を上回るいつでも。
試してみることをお勧めします。本当に重要なことに集中するためにあなたの心を解放します：素晴らしい製品を作る！あなたが私を信じないなら、これを見てください Githubからの素晴らしいプレゼンテーション 。