問題タブ [feature-branch]

Gitまたは（バージョンにもっと興味がありますが、比較は間違いなく役立ちます）のいずれかを使用して次のワークフローを実現するための好ましい方法は何ですか？Subversion Git

• 最近製品のメジャーリリースがあり、と呼ばれる特定のポリシヒンブランチがあるとしましょうrelease-2.0.x。

  その後、開発が継続され、いくつかの機能ブランチがに統合されましたmaster/trunk（これらは後で今後の一部になりrelease-2.1.xます）。

• 現在、ある時点で別の機能（つまり、critical-feature）が開発され、にマージされましたmaster/trunk。この機能は非常に重要であるため、にバックポートする必要があることを認識していrelease-2.0.xます。

これは、説明されているケースの小さな疑似図です。一番上のすべてがrelease-2.0.x現在master/trunkとの間のツリーの違いをもたらし、マージの問題につながることに注意してください（そうでなければ、単純にマージしcritical-featureてこの質問を書かないようにすることができます:)

質問：

• VCS観点から機能のバックポートを実行するための最良の方法は何でしょうか？

• これは、競合を解決する競合を伴うmerge対応するブランチの単純なものとして実行する必要がありますか？critical-feature

• またはcherry-pick、これはコミットのとして実行する必要があります。コミットは、実行時ににマージcritical-featureさmaster/trunkれますか？または、ブランチcherry-picks内の各コミットのセットとしても使用できますか？critical-feature

• 紛争解決の手順について何かアドバイスをいただけますか？release-2.0.xとの現在の違いが非常に大きく、「ナイーブ」なバックポートがコードのリファクタリングや機能の欠落、またはの後に追加されたmaster/trunkために大量の競合を引き起こす場合は、どうすればよいですか？APIrelease-2.0.x

• 標準的なマージまたはチェリーピッキングのアプローチを除いて、このルーチンに提供する特定の何かがありますGitか？競合の量が膨大な場合、リベースSubversionは役に立たないと思いますが、明らかに、私は間違っている可能性があります。

CruiseControl.Netのgitソース管理プロバイダーは単一のgitブランチのみを監視するようです。すべてのgitブランチを監視する方法はありますか？「BranchestoBuild」を「**」に設定することで、Jenkinsでこれを実行できることを知っています。CruiseControl.Netに同様の機能はありますか？

TeamCityとGitHubEnterpriseを使用しています。gitでオープンソース風のワークフローを使用しmainlineます。各コンポーネントにリポジトリがあり、人々が変更を加えたい場合は、

• mainline自分のアカウントにフォークします（したがって、多くのフォークがある可能性があります）
• フォークにブランチを作成します
• 変更を実装する
• mainline/masterその間に発生した変更について最新情報を入手してください
• fork/feature-branch->のプルリクエストを送信しますmainline/master

このワークフローには非常に満足しています。これは、メインラインが変更を確認する前に、コードレビューを強制します（少なくとも手動の手順で、実際にコードを読み取ってテストを実行する必要があります）。これは歴史的に問題でした。作成者がプルリクエストを見ている人である場合は、GHステータスAPI（ブログ投稿、API doc ）を使用して、マージボタンを緑色以外に切り替えたいと思いますが、それは後で行います。

TeamCity 7.1は、メインラインリポジトリを監視し、変更が確認されたときにビルドするように設定されています。ただし、現在の設定方法では、CIはへの変更を確認した場合にのみビルドされmainline/masterます。

同じワークフローを使用できるようにTeamCityでVCSルートをどのように構成する必要がありますが、CIはメインラインリポジトリのフォークのブランチに基づいてビルドをトリガーしますか？ できれば、すべてのフォークを個別に登録する必要はありませんか？

TeamCity 7.1の機能ブランチのドキュメント（ブログ投稿、リリースノート、ドキュメント）を読みましたが、everyone-commitsではなく任意の数のフォークのモデルに適用する方法がわかりません- to-mainline-in-feature-branchs。

コードを「マージ」する標準的な方法として、リベースを使用したいと考えています。また、自動化された統合マネージャーを介して中央リポジトリにプッシュするかなり短期間 (2 週間未満) の機能ブランチも使用します (各開発者には独自の個人リポジトリがあり、変更は最初にそこにプッシュされ、中央リポジトリにプッシュされる場合にのみ変更がプッシュされます)。ビルドとテストは成功しています)

リベースしようとすると、ブランチが分岐したというメッセージが表示され、変更がリベースしたばかりの変更と同じであるにもかかわらず、最初にそこからプルして変更をマージするまで、個人のリポジトリにプッシュできませんでした.

これを避けるために私がすべきことはありますか？それとも、これは私がすでにこの機能ブランチをプッシュしたという事実の結果ですか? ブランチをリベースしたバージョンに置き換えることはできますか?

この状況で推奨されるワークフローはありますか?

最近、私は複数の機能ブランチを開発中であるというこの繰り返しのシナリオを持っているようです。1つの機能ブランチ（下の写真）は、別の不完全な機能（で開発された）feature-bのサポートに依存しています。feature-a

変更するたびにfeature-a（機能のエラーを修正するためのインタラクティブなリベースを含む）、にリベースfeature-bする必要がありますfeature-a。これらはローカルブランチなので、自由に変更できます。

多くの場合、次のようなケースがあります。

ここで、テストブランチは、開発中のすべての（関連する）機能の組み合わせであり、関連するすべての機能ブランチをマージすることによって生成されます（図master、、、および含意によってfeature-b）。feature-cfeature-a

現在、特により複雑な機能のブランチ関係がある場合はgitk、ブランチ関係を視覚化し、このリベースを自動的に行うためのシェルスクリプトを維持するために常に開いていますが、この方法は壊れやすく、一般的に厄介なようです。私が知りたいこと：

1. ブランチの関係を記述し、さらに自動的に検出する方法はありますか？次に、1つのコマンドで、記述された関係を強化してみてください（上記の簡単な例では、feature-aリベースまたはヘッドに新しいコミットを追加して変更した後、自動的にリベースfeature-bを実行しますの新しい頭feature-a）。
2. 一連のブランチを他のコミットにリベースするためのGUIツール（競合によって操作が妨げられる場合は単にエラーを出すだけで問題ありません）？
3. このブランチの混乱を管理する他のアイデアはありますか？偶発的な複雑さは、時間がかかりすぎ、脳力を消耗しすぎています。

同じファイルに影響する 7 つのブランチがあり、すべてセカンダリ ブランチを介してマスター ブランチにマージされています。ブランチの 1 つが安定していなかったため、マージすることを意図していませんでした。その単一のブランチによって行われた変更を元に戻すことはできますか?

私のリポジトリが次のようになっていると仮定します。

現在、D はマスターにあります。私はそれを削除したいです（ただし、b4ブランチに保管してください）。

starteam から Git への切り替えを検討しています。

現在、スターチームでは、特別な名前の「フローティング ビュー」を使用しています。これらのフローティング ビューは、基本的にエイリアスのように機能します。したがって、チェックアウト元の特定のエイリアスを指定でき、現在モデル テストを行っているブランチを取得できます。

これは Git でどのように行われますか? これは、基本的に私たちのブランチがどのように編成されているかです:

これらはすべて枝です

(モデルのテストが完了Branch 2012.05.01すると、 にマージされます。)master

自動化されたスクリプト (ant) では、モデルのデプロイを実行するために、 というブランチからチェックアウトするだけmodelです。このように、モデル テストを行うブランチを変更するときにスクリプトを変更する必要はありません。また、モデル テストを行うビューを見つけることは、modelブランチが参照するブランチを特定するのと同じくらい簡単です。

Gitで似たようなことをする方法はありますか?

明確にするために：

1. ブランチのエイリアスが必要です。コミットではなくブランチ。
2. Branch 2012.05.01は、2012.05.01 に出荷される予定のブランチを意味します。2012.05.01 の瞬間を意味するわけではありません。
3. への別名が欲しいBranch 2012.05.01。Branch 2012.05.01は統合ブランチであり、常に変更されています。しかし、私はそれを として参照したくありません。Branch 2012.05.01として参照したいのですmodel。このようにして、エイリアスを にBranch 2012.07.11変更すると、チェックアウト コード スクリプトを変更せずに、そのブランチから最新のコードを取得できます。

私の現在の開発環境では VCS に git を使用しており、フィーチャー ブランチ ワークフローを使用しています。各機能について統計を生成できるようになりたいと思います。主に、機能が完了するまでにかかった時間を判断できるようにしたいと考えていますが、コミット数、コード行数など、他の統計も見られると便利です.

主な考慮事項は、開発者にとって余分な作業/プロセス ステップを回避することですが、そのタイムスタンプを取得するために、「機能の作業を開始する前に機能ブランチを作成する必要がある」などの単純なことを実装することには反対しません。

必要な情報を収集する最善の方法がわかりません。機能がメインライン ブランチにマージされて削除されると、それが作成されたときの履歴が失われます。

私が見ることができる次の解決策には、post-checkoutフックが含まれます。次のようなもの: https://gist.github.com/4557894しかし、この方法を使用して考えられるいくつかの欠陥があります。

編集: @mr_ndrsn https://github.com/rietta/git_time_extractorで指摘されているように。そのようなツールをコミット/コミットメッセージを超えてブランチに関連付ける方法に関するアイデアはありますか?

私が取り組んでいる 2 つの (プライベート) 機能ブランチがあります。

これらのブランチで少し作業した後、Branch1 の Branch2 からの変更が必要であることを発見しました。Branch2 の変更を Branch1 にリベースしたいと思います。以下で締めくくりたいと思います。

2 番目のブランチを最初のブランチにリベースする必要があることは確かですが、正しい構文と、どのブランチをチェックアウトする必要があるかについては完全にはわかりません。

このコマンドで目的の結果が得られるか?

私は git を使用したブランチ管理の細かい点をいくつか調べており、この記事に基づいていくつかの決定を下していました。

http://nvie.com/posts/a-successful-git-branching-model/

ここで、オリジンにリモートでmasterとdevelopment_branch. すべての開発者に関する限りdevelopment_branch、クローン元の主要な場所であり、安定したリリースがある場合にのみ、開発からマスターにマージします。

それを念頭に置いて、各スプリントを通過する必要があるストーリーがたくさんあるので、現在行っていることは、クローンdevelopment_branchを作成してから、取り組んでいるストーリー/機能の新しいブランチを作成することproduct_description_featureです。その後、このローカル ブランチが処理されるため、別のタスクを取得したり、何らかの修正を行う必要がある場合は、クリーンdevelopment_branchに戻り、そこからブランチすることができます。

ここで、このように動作するプロセスについて質問があります。現在、安全なオプションは次のプロセスのようです。

• クローンdevelopment_branch
• タスクの新しいブランチを作成します (feature_aこの例ではそれを呼び出します)
• feature_aタスクが完了するまでブランチにコミットする
• ローカルに切り替えるdevelopment_branch
• 新しい変更を原点から引き下げます（通常はとにかく頻繁に行われます）
• feature_aからへの変更をマージ development_branch
• development_branchローカルをオリジンにプッシュ
• 次のタスクのために新しいブランチを作成する

これで問題なく動作し、誰もが満足していますが、より定期的にプルしたい次のシナリオを考えてみましょう:

• クローンdevelopment_branch
• タスクの新しいブランチを作成します (feature_bこの例ではそれを呼び出します)
• feature_bブランチにコミット
• ブロッカーに気づき、最新の変更をプルする必要があります
• 切り替えるdevelopment_branch
• development_branchオリジンをローカルにプル
• 切り替えるfeature_b
• development_branchローカルからマージfeature_b
• 完了するまで作業を続ける

これで安全で、誰もが満足しているように見えますが、切り替えてプルダウンし、切り替えてローカル機能ブランチにマージする必要があるかどうかはわかりません。development_branchだから私はここで過度に用心深いだけで、development_branchオリジンからローカルfeature_bブランチに引っ張るべきですか?

local を更新せずに変更を直接ローカルの機能ブランチに取り込むだけなので、これで問題ないようです。development_branch変更をプッシュする必要がある場合は、もう一度切り替え、プル、マージ、プッシュします。

それで、誰かがこれが良い習慣であるかどうかなどを確認できますか?

また、質問をあまり汚しませんが、これらの機能ブランチは各開発者のマシンにのみ存在するため、誰かがタスクを半分実行してから、他の誰かがそれを拾う必要がある場合はどうなりますか? そのブランチをオリジンにプッシュして、それを降ろしてから作業させることができますが、その後、さらにクリーンアップする必要があるため、この問題を解決する良い方法はないと思いますが、その方法を聞いてみたいと思います.他の人は、古い機能ブランチの荒れ地をリモートで作成することなく、問題を解決します。

他にもいくつか言及する必要があります。現在、ffwd マージを行っているところです。元の記事では、ffwd マージではないことについて言及していますが、膨大な量のリモート ブランチを作成せずにこれを行う方法がわかりません。コマンドラインではなく Tortoise GIT を使用していますが、実際には何も変わりません。