問題タブ [git-flow]

Gerrit を使用して「git-flow」のようなワークフローを実装しようとしていますが、パズルの最後のピースを理解できないようです。

私の問題には2つの前提条件があります：

• Gerrit は 1 つのブランチへのマージのみを実行します
• マージ コミットを Gerrit にプッシュすることは許可しません。マージは、変更が承認された後に Gerrit が行う必要があります。

解決したいことは以下です。この git の状況を考えてみましょう:

1 つのコミットを持つ master ブランチと、複数の追加コミットを持つ master からフォークされた開発ブランチがあります。しばらくすると、develop ブランチが master にマージされ、次の製品リリースが作成されます。開発者は、develop からのトピック ブランチと厳密なリベースを使用して作業します。彼らのコミットは、プッシュする前に常に最新のアップストリーム開発の上にリベースされます。これにより、履歴が線形になり、早送りコミットのみが行われます。

ここで、誰かが master からホットフィックス ブランチを作成し、master にマージしたとします。

このコミットはマスター ブランチにのみマージされるようになりましたが、開発者は変更にバグ修正を組み込むために開発ブランチでこのコミットを必要とします。通常、マスター ブランチをマージして開発ブランチを開発しますが、私の前提条件を考慮すると、ローカル マージ コミットが作成されるため、これは不可能です。

私の質問は、開発者による新しい変更にバグ修正が含まれるように、マスター ブランチからローカルの開発ブランチに新しいコミットを組み込むにはどうすればよいですか? 理想的には、スクリプトを変更して、最初にバグ修正の変更をローカルの開発ブランチに適用し (マージしますが、マージ コミットは行いません)、次に開発者のコ​​ミットとプッシュをリベースします。このようにして、バグ修正は新しい変更に自動的に追加され、別のコミットではなく、新しいコミットの一部として表示されます。

私は可能な解決策について考えてきました：

• 開発ブランチへのコミットをチェリーピッキングします。次回開発がマスターとマージされると、これは常に重複したコミットになると思います。これを回避する方法はありますか？
• ここで説明されているようにリベース: http://davitenio.wordpress.com/2008/09/27/git-merge-after-git-cherry-pick-avoiding-duplicate-commits/。これは、開発ブランチが公開されているため、おそらく問題を引き起こしますか?

私の質問が明確であることを願っています。さらに明確にする必要がある場合はお知らせください。私は自分のワークフローにかなり厳格であることを知っていますが、Gerrit と組み合わせると理想的です。それができない場合は、おそらくマージコミットを許可します...

私はgit-flowと多くのトピックブランチ、別名機能ブランチを使用しています。まったく別のルートを取ることが決定されたとき、私は機能ブランチに取り組んでいました。

ここで、そのブランチを削除したいと思います。そこでの作業は開発またはマスターにマージされず、ブランチのリストが「乱雑」になるだけだからです。

しかし、私は歴史的および管理的な目的のためにそのブランチに歴史を保持したいと思います（そして、私たち全員が再び考えを変え、アーカイブされた作品を掘り起こさなければならないという奇妙なチャンス）。

最適なルートは何ですか？私はそれを単純git branch -Dにして、後でその死を起こすことができますか？もしそうなら、そうするためのコマンドは何でしょうか？

私は自分の機能ブランチを開発して最新の状態に保つのが好きです。「git merge --no-ff develop」を頻繁に行うと何か問題がありますか。そして最後に、「git flow feature finish feature1」を実行します。これらのフィーチャー ブランチは共有されています (つまり、他の誰かがそれに取り組んでいるか、自宅のコンピューターで開発している可能性があります)。それらが共有されていない場合、一貫したリベースが優先されますか?

それとも、機能ブランチを最新の状態に保つのではなく、最後にすべてをマージする方がよいでしょうか?

このページを優れたワークフローとして指している多くの参照を見つけたので、ここで説明するワークフローに従います。記事で述べたように、「機能」ブランチは開発者間で共有されますが、中央リポジトリには移動しません。

開発者「A」が。で新しい機能ブランチを開始するとしgit checkout -b newfeature developます。ここで、開発者「B」もこの機能に取り組む必要があるとしましょう。これが私の問題です。

私がしたこと：

1. 開発者「B」は、開発者Aのマシンをリモートとして追加します
2. 開発者「B」が実行しますgit branch remoteA/newfeature
3. 開発者「B」はこのブランチで作業し、作業をコミットして、変更をremoteAにプッシュします。

現在、ステップ3は機能していません。メッセージが表示されます：

remote：error：デフォルトでは、非ベアリポジトリの現在のブランチの更新は拒否されます。これは、インデックスと作業ツリーがプッシュしたものと一致しなくなり、作業ツリーと一致するように「gitreset--hard」が必要になるためです。頭へ。

remote：error：リモートリポジトリで「receive.denyCurrentBranch」構成変数を「ignore」または「warn」に設定して、現在のブランチにプッシュできるようにすることができます。ただし、他の方法でプッシュしたものと一致するように作業ツリーを更新するように手配しない限り、これはお勧めしません。

remote：error：このメッセージをスケルチし、デフォルトの動作を維持するには、receive.denyCurrentBranchの構成変数を「refuse」に設定します。

私はすでに設定sharedRepository = trueしましたが、それは役に立ちませんでした。

2つの質問があります：

1. 開発者間で機能ブランチを共有する正しい方法は何ですか？
2. 開発者Bのリポジトリの変更を開発者Aの元のリポジトリにプッシュバックするにはどうすればよいですか？

私は現在、git-flowをよく調べており、自分が関わっているプロジェクトでgit-flowをどのように使用するかを理解しようとしています。

私はさまざまなgit-flowチュートリアルを見てきましたが、gitについてはかなりよく知っています。したがって、gitだけのヒントは必要ありませんが、git-flowを使用したワークフローについて直接説明する必要があります。

状況は次のとおりです。

バージョンをリリースすると（1.0と呼びましょう）、これは開発の分岐になります。これは問題ありません。今、私が2.0で作業を開始し、新しい機能を追加しているとしましょう。そしてもちろん、完了したら、それらをマージして開発に戻したいと思います。これで、1.0での修正プログラムは問題ないので、いくつかのバージョン1.0.1、1.0.2などを作成するとします。これらはすべて開発ブランチも更新します。これも素晴らしいことです。これまでのところ面倒ですが、2.0の機能と1.0.xの修正プログラムを個別に開発できます。

ただし、誰かが1.1リリースの新機能を要求したとします。今、私は問題を抱えています。機能ブランチを作成する場合、これは開発ブランチに基づいており、このブランチにはすでに2.0のものが含まれている可能性がありますが、この1.1リリースでは必要ない可能性があります。

これらの2.0と1.1の変更を独立して処理する簡単な方法はありますか？

私がすでに見ているいくつかの可能性があります：

• 開発の最後のリリース位置に新しいブランチを作成します。開発をこの位置にリベースし、他の開発ブランチの名前を変更します。ただし、このブランチには1.0.1などのホットフィックスは含まれません。

• 2.0が完了する前に、2.0の機能をマージして戻さないでください。ただし、最後の瞬間まで、マージされていない多くの変更を開いたままにしておく必要があります。また、2.0 getがリリースされ、その後1.0.xへの変更が要求された場合、これは役に立ちません。

これはgitflowでまったく可能ですか？つまり、新しいリリースの作業が開始または終了した後は、以前のリリースに基づいてリリースしますか？

私は git と git flow が初めてです。さまざまなページ、ブログ、stackoverflow に関する質問をすべて読み、日々の開発に使用しています。

しかし、1 つの問題が私を悩ませてきました。フィーチャー ブランチは小さくあるべきであることは知っています。フィーチャーを開始し、その一部をコーディングしてから、フィーチャーを完成させます。これは日常的な出来事です、私はそれを理解しています。開発ブランチが常にビルド可能であることを確認するだけです。

しかし、機能の途中で、完成させる準備ができていないのに作業の優先順位が変わった場合はどうなりますか? 別の機能に切り替えられるようにしたいです。

たとえば、私は新しい機能を開始します。

私はコードを書いたり、ファイルをコミットしたりしています...そして順調に進んでいます。しかし今、私が取り組んでいるものを変更する必要があります。主に、利用できないリソースが必要で、サーバー コーダーが 1 日か 2 日で準備ができていないためです。開発ブランチが壊れてしまうので、機能を完成させることができません。

私はこのようなことをしたいと思います:

実際、「git flow feature list」コマンドの存在は、複数の機能を同時に実行できることを意味します。しかし、機能を作成または切り替える方法がわかりません。実際、これは git フローの問題ではなく、git の問題だと思い始めています。

助けていただければ幸いです。ありがとう！

本番コードに git を使い始めたばかりですが、ワークフローでわずかな問題が発生しています。機能の作業中に発生する一般的なコードの改善/技術的負債の修正を処理する方法を理解する必要があります。

私たちが採用したワークフローは、「開発」をメインの統合ブランチとして使用し、「開発」から離れた機能ブランチですべての機能を開発することです。機能が完成すると、開発者はプル リクエストを作成し、全員がそれをレビューしてコメントを提供してから、開発にマージします。これは非常にうまく機能しているようです。

私たちが抱えている問題は、機能の日常的な開発中に、開発者がシステムを改善したり、技術的負債をクリーンアップしたりするために、一般的なコードを変更/リファクタリングしたくなる場合があることです。この変更は価値がありますが、開発中の機能とは直接関係ありません。

私たちのワークフローに基づいて、開発に入る前に独自のプル リクエストとコード レビューを通過する別のブランチで実際に実行する必要があります。ただし、これを実行してもらう場合、完全なコード レビューが行われ、コードが開発にマージされるのを待っている間に、変更を機能ブランチに戻すにはどうすればよいでしょうか。

私たちが持っているアイデアは次のとおりです。

1) 「refactorX」ブランチから機能ブランチへの変更をチェリーピックします。開発を続けて、リファクタリング ブランチからの変更が既にあることを開発にマージするときに、git に (できれば) 理解させます。

2) 「refactorX」ブランチを機能ブランチにマージし、開発を続けます。(注: 「refactorX」の開発の分岐は開発の歴史の後半にある可能性があるため、これには問題があると考えられます)

3) まだわかっていない他のよりスマートなオプション。:)

私たちが探しているのは、ワークフローのこの部分を処理する方法に関するベスト プラクティス ガイダンスです。それについてもっと話し合った後、それが頻繁に発生することを知っており、ワークフローでそれを処理するためのスムーズで効率的な方法を見つけたいと考えています.

推奨事項はありますか？

私はまだ git から git-flow に移行しようとしています。私は git-flow 内であらゆる種類の git 機能を使用できることを知っていますが、それが自動的に処理するものに最も興味があります。

Alice と Bob という 2 人の開発者がいて、それぞれ機能 A と機能 B に取り組んでいるとします。Alice が完了したら、コミット C に基づいてgit flow feature finish Aローカルdevelopブランチにマージ コミットを作成することができます。ここで、ボブが機能を同時に終了し、同じものを取得した場合、彼のマージ コミットも C に基づいたものになります。アリスがプッシュし、ボブが再びフェッチした場合、彼はマージまたはリベースする必要があり、彼がマージdevelopした場合に備えて、ブランチに非線形の履歴が残ることになります。

これはこれまでのところ正しいですか、それとも git-flow は何らかの方法でこの状況を自動的に処理しますか? 自動メカニズムがある場合、これが機能するためには何を設定する必要がありますか?

最も簡単な解決策は、機能を終了する前に常にフェッチすることでしょうdevelop。ただし、リポジトリの共有方法によっては、これが実際に可能かどうかはわかりません (その時点では利用できない可能性があります)。

編集（問題の説明）：

答えが示唆するように、私の例は明確ではありませんでした。だから最初に私が問題だと思うものの写真：

C は、develop ブランチの最初のコミットです。

Alice は機能ブランチでいくつかの機能作業を作成します。

同時に、ボブは別の機能にも取り組んでいます

これで Alice は機能を終了し、マージ コミットが追加されて開発されます (私はそれが必要です)。

ここで、Bob が機能を終了し、再びマージ コミットが追加されて開発されます (別の場所でもそれが必要です:

ただし、Alice または Bob のいずれかが開発をマージして、追加のコミットを作成する必要があります。

私が代わりに持ちたいのは次のようなものです：

ご覧のとおり、履歴は依然として非線形ですが、develop ブランチのメイン ラインには機能からのマージ コミットのみが含まれます (他の場合のように追加のマージ コミットは含まれません)。

これについて私が気に入っているのは、履歴の変更を簡単に追跡して、それらが以前の機能ブランチに属しているかどうか、または開発中のマージであったかどうかを確認できることです。このすべての情報は、DAG から直接取得できます。

また、develop 時のマージ コミットに適切なメッセージを使用する場合、2 番目のケースでは、develop の最初の親を常にフォローすることで、変更ログを簡単に取得できます。ただし、2 番目のケースでは、最初の親のみをフォローする必要がある場合もあれば、複数の親をフォローする必要がある場合もあります。そして、コード化できることをいつ行うか、簡単な方法がわかりません。

私たちは git に移行しています。分岐と並列開発をより適切に処理するソース管理が必要です。私たちのチーム全体が少し調査を行った結果、git に移行することにしました。gitflowのモデルも気に入っています。git 用の gitflow 拡張機能もあることに気付きました。

この拡張機能は、標準の git よりもどのような利点がありますか? コマンドをまとめるマクロがメインのようです。gitflow 拡張機能を気にする必要がありますか (モデルは気に入っています)。それは役に立ちますか？標準の git コマンドと比べてどうですか?

しばらくの間git-flowを使用していますが、まだタグ プレフィックス機能を理解していません。release/すべてのタグの前に付けるのは単なる文字列だと思います。これを行うことの使用例や利点はありますか? Git Flow のブログ投稿のいずれにも、その説明はまだありません。