問題タブ [feature-branch]

私は、フィーチャー ブランチを git のプレビュー ブランチに時折公開する最良の方法を理解しようとしています。これが私のセットアップです：

1. クライアントは機能を要求します。
2. 初期機能を開発し、プレビュー/テスト サイトに公開します。
3. クライアントがフィードバックを提供します。
4. さらに変更を加えます。
5. ステップ 3 に数回進みます。
6. クライアントは機能に適しています
7. 機能を本番サイトにプッシュされる単一のコミットにリベースします。

いくつかの異なる機能が一度に開発される可能性があり、クライアントが開発中のこれらすべての機能を確認できる「プレビュー」サイトは 1 つだけであることに注意してください。現在の私のgitワークフロー。

したがって、最終結果は次のとおりです。

1. 本番環境に移行するときに、独自の分離されたブランチとコントロールで機能を開発することができました。また、きちんとしたコミットとして本番環境にロールアップされます。
2. クライアントは、私が開発してフィードバックを提供する機能を確認できます。彼らはまた、私が同時に開発している他の機能と一緒にその機能を見ることができます.
3. 「プレビュー」ブランチは、「WIP」コミットと最終的なリベース コミットの両方を取得するため、少し厄介になります。しかし、それはクライアントのプレビュー用であるため、それほど気にしません。必要に応じて、定期的にブランチを削除してマスターから再作成できます。

私の唯一の問題は、予想よりも多くの競合が発生しているように見えることです。これは、ステージングが開発コミットと最終コミットの両方を取得しているためだと考えています。これを行うためのより良い方法があるかどうかも疑問に思いますか？

マスターには、機能ブランチに住むほうがよいファイルがいくつかあります。そのようなブランチを作成してそこにファイルを配置すると同時に、マスターからファイルを削除したいと思います。

履歴については気にしません。つまり、ファイルを以前のコミットから削除する必要はありません。私がする時

HEADの状況は私が望むようなものです。ただし、マスターを機能にマージするときに問題が発生します。私はそれに対処する必要がありますか、それともそのようなシナリオの解決策はありますか？

私はリモートブランチを削除する方法を知っているので、この質問はそうではありません： 古いリモートgitブランチをクリーンアップする方法 や githubで廃止されたブランチを管理する方法

むしろ、私の問題は、古い機能ブランチを削除するとコミットメッセージが失われ、JIRAがタグを発行することです。したがって、JIRAからの特定の問題に対して行われたコミットを確認できなくなります。

gitブランチ-リストからリモートブランチをクリーンアップ、クローズ、または非表示にする方法はありますが、JIRAのgitプラグインがその処理を実行するために必要なメッセージを破棄しないでください。

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

開発者「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の元のリポジトリにプッシュバックするにはどうすればよいですか？

これが私のシナリオです：

• 私のプロジェクトは、トピック分岐パターンに従っています。

• いくつかの問題を修正するためにブランチを作成します。このブランチを problem_fixes と呼びましょう。変更を加えて、プル リクエストを送信します。

• 新しい機能の作業を開始する必要があるため、my_feature という名前の 2 つ目のブランチを作成し、一連の変更をコミットします。

• ある時点で、my_feature がまだ受け入れられてマージされていない problem_fixes に依存していることに気付きました (my_feature ブランチは最初のブランチからの修正の一部に依存しており、それらなしでは先に進むことができません)。

最初のブランチをより迅速に受け入れてマージするようにプロジェクト リーダーにバッジを付ける以外に、ここに従うべき最善のプロセスは何ですか?

problem_fixes (master ではなく) に基づいて新しい 3 番目のブランチを開始し、コミットを my_feature にマージする必要があるかどうか疑問に思っています。または、problem_fixes を my_feature にマージして作業を続行しても問題ありませんか? problem_fixes が最初に master にマージされると仮定すると、my_feature がマージされると、理論的には問題ないはずです (?)。

バグの解決策をテストするために作成され、レビュープロセスで間違っているか、問題のより良い解決策があることが示されたためにマージされていないgitブランチの現在のベストプラクティスは何ですか？

例。プロジェクトfizzbuzzには、空のフィールドでのクラッシュを報告するバグレポートがあります。

• 新しいブランチを作成し、handle-empty-fieldsそのブランチに2つコミットして、問題を「解決」します。
• 次に、そのブランチをfizzbuzzプロジェクトマネージャーに送信し、バグレポートにリンクします。
• 誰かが私の修正でエラーを見つけ、別のパッチを書き、そのパッチが受け入れられます。

これで、handle-empty-fields私のコードのコードは役に立たなくなりました。正しくなく、コードに適用できなくなりましたが、そのバグレポートで参照されています。

私は何をすべきか？ブランチを維持しますか？私はすぐに数十の放棄されたブランチになってしまい、gitにはブランチを放棄または閉じたものとしてマークする方法がありません。ブランチを削除しますか？しかし、そのバグレポートを見ている人は、それを見つけて404を取得します。

他の開発者、特にダウンストリーム開発者に問題を引き起こすため、リポジトリをリベースしないように勧められることがよくあります。機能またはバグ修正ブランチの提案は何ですか？

更新：githubがプルリクエストに含まれるコミットを削除しないようです。したがって、変更をプッシュしてプルリクエストに変換すると、変更を失うことなく、後でブランチを削除できます。まあ、githubがまだ動作している間;）。

最近gitflowを使い始めたばかりですが、よくわからないことがあります。まず、開発に関して直接何もしません。何かをする場合は、ホットフィックスまたは機能の開始を使用します。

新しい機能（「sequentialUpgrades」）を開始したとき、プラグインはバージョン1.1.5でした。それは4日前でした。過去4日間で、この新機能を完了していませんが、2つの修正プログラムを完了したので、それらをマスターにマージし、完了時に開発しました。もちろん、これらのブランチの両方で、修正プログラムを含む最新の変更があります。バージョン1.1.7で...私が実行した場合git diff master develop、違いはありません。

機能ブランチに戻ってこの新機能の開発を続けたところ、機能ブランチはまだ1.1.5に戻っているため、最新の2つの修正プログラムはありません。

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

1. 何かを台無しにすることなく、最新の変更を機能ブランチに取り込む方法があるとしたらどうでしょうか。

開発を機能ブランチにマージすることを考えていましたが、それが正しい方法ではないと思います。しかし、私は本当に、この新機能の開発中にこれらの最後の2つの修正が存在する必要があることをスクラッチしたいと思います。

2. これができない場合、機能を終了したときに、競合することなく、どのように統合して開発に戻すことができますか？これに頭を包むことはできません。

この機能を1.1.5から始めたからです。機能ブランチで、ファイルaccess-level.phpに大幅な変更を加えました。修正プログラムを実行したときに、同じファイルの5〜6行を変更しました。いくつかの重要な変更が加えられた1.1.5に戻ったファイルを、それ以降も変更が加えられた1.1.7の同じファイルにマージするにはどうすればよいですか？

バージョン管理に使用svnしていますが、次の質問があります。

• 私が自分の中で何かを開発し、feature branchから常に上流の変更を開発しているとしましょうtrunk (単純にそれらをマージして競合を解決することによって)。さて、ある時点で、最後のアップストリーム マージを作成しtrunk、競合を解決しました。そして、たとえば、その直後mergeに何とか「フリーズ」することができましたtrunk-すべてのコミットtrunkが拒否され、常に同じ状態のままです。

• これにより、 を実行するときに競合が発生しないことが保証されmerge --reintegrateますfeature branchか? または、それらにつながる可能性のある他の条件やアクションが欠落していますか?

この記事を読んだ後、メインブランチから私の機能ブランチに変更を収集するためにリベースすることは理にかなっています： Gitワークフローとリベースとマージの質問

これは、機能ブランチが私のマシンに対してローカルであり、履歴を好きなように書き換えることができる場合にうまく機能します。

しかし、機能ブランチで他の誰かとコラボレーションした場合はどうなりますか。機能ブランチがリモートリポジトリに保持されているので、メインブランチから機能ブランチに最新の変更を取得するにはどうすればよいですか？

だから私たちはマージしますか？または、これを行うための別の巧妙なGITメソッドはありますか？

前もって感謝します！

私のチームは機能ブランチを使用して新しい機能を実装し、ユーザーが使用できるようにスナップショット ビルドをリモート リポジトリに継続的にデプロイしています。したがって、「デプロイ」は実際には「リモート Maven リポジトリへの配布」を意味するだけです。現在、次の理由により、マスター ブランチの継続的インテグレーション ビルドのみを実行しており、フィーチャー ブランチでは実行していません。Maven を使用してプロジェクトをビルドし、JavaDoc とソースを JAR と共に配布しています。

私の計画は、各機能ブランチのビルドに分類子を追加することであり、次のような成果物を作成およびデプロイするときに使用されることを期待していました。

• ブランチ: マスター
• 分類子: なし

• アーティファクト: foo-${version}.jar、foo-${version}-sources.jar、foo-${version}-javadoc.jar

• ブランチ: 機能-X

• 分類子: myfeature
• アーティファクト: foo-${version}-feature.jar、foo-${version}-sources-feature.jar、foo-${version}-javadoc-feature.jar

アーティファクトの正確な名前はあまり気にしません。機能ブランチ用にメイン、ソース、および JavaDoc アーティファクトを個別に必要とするだけです。JavaDoc プラグインもソース プラグインも分類子が構成されているとは見なさないため、マスター ビルド用に作成されたアーティファクトを効果的に上書きします。

おそらく問題は解決しますが、artifactId を変更したくはありません。機能ブランチと Maven との継続的統合にどのようにアプローチしますか?