問題タブ [feature-branch]

次のように、フィーチャー ブランチと Git を使用する典型的なユース ケースがあります。

ブランチ「1.24」からのコミットを適用せずに、機能ブランチをマスターにリベースしたいのですが、すべてのパラメーターを指定してコマンドラインからこれを行うことができましたが、Eclipseからこれを行うグラフィカルな方法をまだ見つけることができません。

これらの場合、あなたは何をしますか？マージでも同じことが起こっています。これは GitFlow ワークフローの非常に一般的なシナリオだと思います。

master にマージされた機能ブランチに変更を導入する方法を探しています。目標は、機能ブランチに関連するコミットのみを保持することです。

機能がすでにマスターにプッシュされた後、追加の研磨が必要になることがよくあります。その間に master に対して行われた変更は、機能と競合していません。つまり、機能ブランチに追加の作業を実装するときに、実際の master へのリベースが可能です。

以下の画像はその状況を示しています。

私がこれまでに使用したアプローチ：マスターにリベースし、機能をマスターにマージします

反対 -> 機能ブランチは現在、マスターからのパーツで汚染されています。

質問: この問題を解決するために実際に取っているアプローチは何ですか?

サンプルコード

以下のアプローチを説明するのに役立つのは、例からリポジトリ構造を作成するコードです。

チームで Git Flow を使用しています。私たちは皆、機能の開発から分岐し、コード レビュー後に再びマージします。これは私たちにとってはうまく機能しますが、開発者が完了するまでに 1 か月以上かかる機能が 1 つあります。この間にいくつかのリリースがあります。

これを促進するためのいくつかの質問：

• これをどのように処理する必要がありますか？
• このように処理する必要がありますか？
• それとも、機能をより小さなマージ リクエストに分割する必要がありますか?
• それを切り刻む場合、それが公開プロジェクトである場合、この機能の一部が進行中のリリースに影響を与えないようにするにはどうすればよいでしょうか?
• この長期的な機能ブランチへの開発のマージは本当に悪いことですか? 私の同僚は、それがアンチパターンであることを懸念しています。
• この長期的な機能に一貫して開発をマージしなければ、機能が最終的に完成したときに悪い結果が生じる可能性はありますか?

私は会社の顧客向けサービスを担当しており、3 月末までに「ビッグバン」で会社のブランドを変更する予定です。そのため、すべての製品はその特定の日に新機能と新しい CI とともにリリースされます。 .

私がしなければならない作業は 1 ～ 2 日と見積もっていますが、デザイナーと相談するのに十分な時間を確保するために、3 月の初めに開始する可能性があります。デプロイメントは master ブランチの先頭から直接スケジュールされているため、ブランド変更をどのように行うのか疑問に思っています。マスターでそれを行う場合、リリース ブランチからサービスをデプロイする必要があります。そこでは、ブランド変更を行わないコミットを半月間チェリー ピックします。これは、新しい CI を誤って展開するのが簡単すぎるため、他の開発者、特にマネージャーの展開パイプラインへのログインを無効にする必要があることを意味します。

その観点からすると、フィーチャー ブランチが最適なように見えるかもしれませんが、それは醜いことではありませんか? 正しい方法は？

リポジトリを複製し、hg(経由で) 機能ブランチを作成しましたhg branch myfeature。私はそれに変更をステージングしてコミットしhg add .、その後hg commit -m "My new feature branch.".

他の開発者がブランチの変更をコードレビューできるように、これらの変更を (ブランチではなく) リモートサーバー (プロジェクトのクローンを作成した場所)にプッシュしたいと思います。defaultmyfeature

次の使用を推奨するブログを見つけました。

しかし、これは私にとってはうまくいきません - 私がうまくいかないアイデアはありますか?

私は、一部のチームが既に機能分岐を使用して継続的デリバリーを達成しようとしているのに、機能切り替えを使用する理由を理解しようとしています。チームが継続的デリバリーを達成したいと考えており、機能の切り替えまたは機能の分岐の助けを借りてそれを行うことができるとしましょう。

機能の切り替えには、実装可能ないわゆる「リリース切り替え」があり、チームはより迅速にリリースできます。機能の準備ができておらず、マスター ブランチのみを使用している場合は、それを切り替えてコードをリリースできます。

機能分岐についてもほぼ同じ話です。ここでは、たとえば、開発中の 3 つの機能を使用でき、そのうちの 1 つは既に完了しています。次に、会社はチームが本番環境にデプロイすることを望んでいます。彼らはその機能だけを選び、それをマージしてリリースします。

一部のチームが開発時に両方のアプローチを使用しているのを見てきました。この分野での経験がある人は、それについて何か教えてもらえますか?

ご理解いただければ幸いです。

以前にsvnを使用していたgitに少し混乱しています。

メイン ブランチからプルし、機能ブランチを作成し、それに取り組み、変更をローカルに追加してコミットし、リモートにプッシュして、ブランチをジェンキンスに送信し、すべてのテストに合格しました。

その間、メイン ブランチは移動したので、開発をチェックアウトし、最新の変更をプルしてから、開発の最新コピーに対してブランチをリベースしました。

したがって、これは、単体テストと統合テストがコードの最新のコピーに対して実行されたが、開発の最新のコピーに対して実行されなかったことを意味します。

これで変更をリモート ブランチに再度プッシュして開発に最新の変更を加え、テストを再実行できると思いましたが、git ステータスにはコミットするものは何もなく、作業ディレクトリはクリーンであると表示されます。

私のブランチが、テストを再実行するためにプッシュしたい開発への変更があることを認識しないのはなぜですか?