問題タブ [feature-branch]

この質問はgit rebase interactive: squash merge commits togetherに非常に関連しています。

特定のプロジェクトの新しい機能を作成しているとします。たとえば、特定のブランチから開始し、develフィーチャー用のブランチを構築しますfeature/X。ときどき、プロジェクトでいくつかの問題を見つけることもあるので、あなたはfixesから始まるという名前の 2 番目のブランチを構築することにしましたdevel。

修正を随時適用する必要があるため、時々feature/X実行し続けると、次のような状況になります。git merge fixes

これは決してプッシュされなかったので (他の誰かの履歴を壊すことはありません)、すべてのマージを 1 つに因数分解して、次の結果を得たいと思います。

この結果を得る方法は、

これは実際に仕事をしますが、feature2後でマージのコミットメッセージに表示される別のブランチを作成する必要があります。また、2 つ以上のブランチで作業しているときに試してみてください。

これを行うよりエレガントな方法はありますか？便利なコマンドの価値がある操作と思われるので、ショートカットがあると思います。

ご協力いただきありがとうございます

小さなチーム ( Gitflowではない) でフィーチャー ブランチワークフローを使用する場合、マスターで以前にタグ付けされたリリースにホット フィックスを適用するための規則はありますか?

例えば：

1. v1.0.0 は特定の時点でリリースされ、その時点でタグが作成されます。
2. 開発者は機能ブランチの作業を続けており、完了時に master にマージされ、v1.1.0 の遠い将来のリリースに備えてレビューされます。
3. お客様に問題が発生し始め、v1.1.0 の進捗状況を除外して、v1.0.0 (v1.0.1 と呼びます) へのホットフィックスをリリースする必要があると見なされます。

Gitflow では、マスターはタグ付けされたリリース (マスターからのブランチ、修正、マスターへの修正のマージ、マスターからのリリースおよびタグ付け) のみで構成されているため、ブランチ構造は明らかです。Feature Branch ワークフローでは、これが通常どのように処理され、わかりやすい履歴が保持されるかを知りたいです。

の機能を開発中feature/xです。この機能を時々 にマージし、同期を維持するために にマージする必要がmasterありますmaster。feature/xブランチはfeature/xリモート ブランチとしても存在するため、リベースはあまり良い選択肢ではありません。

master将来のある時点まで、実際の機能を無効/非表示にしたいと考えています。master実際、 UI で非表示にすることで開発中の機能を無効にするが、基になるメカニズムを保持するように、コミット K を作成できるようにしたいと考えています。

また、からmasterにfeature/xマージするときに、K を除くすべてのコミットを取得できるように、これを機能させたいと思います。feature/xmastermaster

私はもう試した

masterこれは、私が行うときに機能が再度有効になることを除いて機能します

そのため、-s oursfrom mastertofeature/xとマージしても、両方の方法でマージされるわけではないようです。feature/xしたがって、 からにマージするたびにmaster、機能を再度無効にする必要があり、その後、この無効化コミットが に戻りfeature/xます。より良い方法はありますか？

git とグッド プラクティスについていくつか質問があります ...

git リポジトリの状態は次のとおりです。

私はマスターを持っており、1.0 と 1.1 の 2 つのバージョンがあります。

新しい機能を開発する必要があり、V1.1 とマスターの 2 つのブランチに適用する必要があります。

それを行うためのより良い方法は何ですか? 機能ブランチを作成する必要があると思いますが、どれに基づいていますか? マスターまたは V1.1?

開発が検証されたら、最適なマージ戦略は何ですか? マージしますか？チェリーピック ? リベース？

機能ブランチは上流にプッシュされます。これに取り組むのは私だけではないからです。また、複数のコミットがあります。

ご協力いただきありがとうございます ！

機能ブランチが master に基づいている場合、次のようになります。

機能の開発が完了したら、master と topicbranch を簡単にマージして、新しい機能を master に追加できます。

しかし、コミット E、F、および G を他のブランチ (CB の直後) に追加する方法は? と思うところです

コミット D も追加されるため、機能しません。

私は自分の会社で git-flow を使用してしばらく経ちましたが、特定の状況に何度も遭遇し、私を困惑させました。git-flow を介して既存の公開済みサイトに新しい機能を統合するためのベスト プラクティスを見つけようとしています。これらの機能をテストしてから、別のグループに公開する必要があります。

ステージング サイトと本番サイトの両方をセットアップしました。開発ブランチからステージング サイトにデプロイし、開発ブランチに問題がないように見えたときに git-flow リリースを実行し、マスターから運用サイトに変更をデプロイしたいと考えています。すべての変更を一度に公開できる限り、これは問題なく機能します。最近、クライアントから、変更命令をまとめて公開するよう多くのリクエストがありました。つまり、私は 4 つの機能に取り組んでおり、そのうち 2 つを 1 週間で公開し、残りの 2 つを 2 週間で公開することを望んでいます。git-flow フィーチャー ブランチを使用し、一緒に公開する必要があるブランチを「終了」するだけで問題が解決すると考えましたが、さらに多くの疑問が残りました。

新しい機能ごとにフィーチャー ブランチを作成するとき、別のフィーチャー ブランチにコミットした css や js を使用する必要があることがよくあります (それはそのブランチにも関連しているためです)。また、git-flow でこれらのブランチを開発に「終了」するときに、多くのマージ競合に対処する必要があると感じています (それらのコミットは多くの同じファイルを共有するため)。クライアントは、私が行っているすべての変更のアクティブなバージョンも見たいと思っています。それらをさまざまな機能ブランチにサイロ化した場合、それらを開発にマージまたはリベースしない限り、それらを一緒に表示する方法がわかりません。分岐し、ステージング サイトにプッシュします。これは、それらをまとめて公開する機会を台無しにしてしまいます。テスト用に別のブランチを作成し、このブランチで機能ブランチをリベースすることを考えました。

これらの要件を満たすことができるワークフローが見つからないようですので、お役に立てば幸いです。

私は亀のsvnを使用しています。しかし、私は一般的にsvnにはかなり慣れていません。ただし、gitの経験はあります。

ドキュメントではそれは言う

ブランチを再統合する

この方法は、Subversion ブックで説明されている機能ブランチを作成した場合に対応します。すべてのトランクの変更は、週ごとにフィーチャー ブランチに移植されました。これでフィーチャーが完成し、トランクにマージし直します。

私が理解している限りでは、機能ブランチの通常のワークフローは、機能ブランチを作成し、その上で開発を行い、トランク ブランチのバグ修正からリビジョンの範囲を頻繁にマージすることです。機能が完了したら、トランクの変更の最終的なマージを行い、ブランチをトランクに再統合します。

だから私はいくつかの質問があります：

1. このワークフローは正しいですか
2. 機能ブランチを再統合する前にトランク ブランチからの変更をマージしないとどうなりますか
3. 完全に更新されたフィーチャー ブランチからトランク ブランチに通常のマージを実行するとどうなりますか
4. なぜこれがそれほど複雑なのか、svn は git よりもユーザーフレンドリーであることを意図していますが、特にマージでは、機能ブランチにマージするリビジョンを指定する必要があり、さまざまなマージオプションから選択することは、同等の git 機能よりもはるかに複雑に見えます(私は会社で svn を使用する必要があります。他の開発者が使用しているため、彼らは分岐を行いません)、私が何か間違ったことをしていない限り