タグ付けされた質問 「branching」

プロジェクトのチームを単一のメイン/トランクブランチから、メインに定期的にマージする必要がある複数の開発/ワークブランチに移動しています。この記事とTFS分岐ガイド（TFSとVisual Studio 2010を使用しています）に基づいて新しいプロセスを作成しています。 現在、1人から5人の人々がプロジェクトに取り組んでいます。Mainは必要に応じていつでもリリースできるようにするため、常に安定している必要があります。スプリントは修正されていません-少なくともまだ-現時点では1〜2週間ごとにリリースしています。 この時点で、各ユーザーはアプリケーション全体のバグを修正しています。数週間以内に、アプリの新しい大きなコンポーネントの開発を開始します。 私たちが見つけている一つのこだわりのポイントは、いつ開発ブランチを作成すべきかということです。開発者のスキルセットに応じて、複数のユーザーストーリーを並行して実装します。開発者ごとにブランチを作成することを考えましたが、それは意味がありません。作業の一部で常にコラボレーションが必要になるからです。他の作業が完了している間にMainにマージするため、単一の開発ブランチでは対応できません。 誰にもこれに関するガイダンスがありますか？

11 development-process  team-foundation-server  branching 

プロジェクトの個々の開発者ごとにリモートブランチを用意することは良い習慣と考えられますか？ 次のブランチでGitを使用しています。 主人 解放する 発展させる 各開発者が独自のブランチを持っている場合、彼らはコードを自分のブランチにプッシュし、他の開発者はこれらの変更を独自のブランチにマージできます。

11 version-control  git  branching 

私の職場のチームは、VCSとしてSubversionを使用して新しいプロジェクトを開始しています（この質問の目的のために、これは固いものと考えることができます）。私たちはまだプロジェクトの初期段階にあり、分岐モデルについて合意しようとしています。以前のプロジェクトは非標準バージョンモデルに基づいていたため、既存のリリースのホットフィックスとパッチを管理するときに問題が発生しました。 さまざまな分岐モデルがかなり複雑であることがわかりましたが、私がかなり明確に理解しているモデルの1つはgit flowです。Subversionでこれのバリエーションを実装するのがどれほど難しい/望ましくないか知りたいです。明らかに、ブランチで協力している人々の点でいくつかの違いがあります。機能ブランチはローカルリポジトリに限定するのではなく一元化する必要がありますが、モデルの他の概念は、私が理解しているようにSubversionで再現可能でなければなりません。 このアプローチの欠点または課題は何でしょうか。私が聞いたのは、SVNではGitに比べて「マージは高価です」ということです。しかし、これが実際に何を意味するのか、それがブランチモデルのようなgitフローを使用する能力にどのように影響するのかについては、完全には明らかではありません。 このアプローチの最大の懸念は何でしょう。Subversionでより自然な同様の明確なアプローチはありますか？

10 svn  branching  gitflow 

私は適切なブランチの命名について私のリードとの不一致（もちろん、コーディアル）の真っ最中です。これは、バグ修正と小さな機能ブランチに適用され、長時間実行される機能ブランチには適用されません。長期間実行される機能ブランチの場合、人間が読める名前の方が優れていることに同意します。2つの視点があります。 私の： チームとチケット番号に従ってブランチに名前を付けた方が良いです。チケットシステムでそれらを見つけやすくなり、入力が短くなります。また、チケットに関する履歴情報を検索するときに、GITで関連するブランチを簡単に検索できます。 例： team-name/12345 team-name/53719 彼： 機能/機能に従ってブランチに名前を付けます。オートコンプリートが簡単になり、個々の数字より覚えやすくなります。 例： team-name/fix-that-sql-bug team-name/expand-http-parser 私が提供した1つの妥協点は次のとおりです。 team-name/12345-fix-that-sql-bug しかし、GITのオートコンプリートに干渉するため、彼はこれを好みません。 これが主に意見に基づいている場合は、これがどのようにSOに適しているかについてのガイダンスを遠慮なく教えてください。

10 git  naming  github  workflows  branching 

Subversionで1つのブランチのみを処理する場合、気にする必要がありますか？トランクで作業を高速化することはできませんか？ これは、Subversionで開発する方法です。 トランクあり 新しい開発ブランチを作る そのブランチで新しい機能を開発します 機能が完了すると、トランクにマージされ、ブランチが削除され、トランクから新しい開発ブランチが作成されます プロダクションにリリースしたいときは、トランクからタグを作ります。バグ修正は、そのタグからのブランチで行われます。このバグ修正はトランクにマージされます。 これが、機能の完了後に新しい開発ブランチを作成する理由です。このようにして、バグ修正はすぐに新しいコードに含まれます。 以下は明確にする必要がある図です： これは、これが最も効率的な作業方法ではないという感じがあります。コミットする前にローカルでビルドします。これには5〜10分かかります。これはかなり長い待ち時間として経験されていることを理解できます。 開発ブランチの考え方は、トランクは常にリリースの準備ができているということです。しかし、これは私たちの状況ではもう当てはまりません。場合によっては、機能の準備がほぼ整っており、一部の開発者は既に次の機能のコーディングを開始します（そうでない場合、1人または2人の開発者が完了してマージするのを待っています）。 次に、機能1が完了すると、トランクにマージされますが、機能2の一部のコミットが含まれています。 では、ブランチは1つしかないので、開発ブランチを気にする必要がありますか？私はトランクベースの開発と抽象化による分岐について読んでいますが、ほとんどの記事は抽象化による分岐の部分に焦点を当てています。数回のリリースにまたがる大きな変更の印象を受けました。これは私たちが抱えている問題ではありません。 どう思いますか？トランクで作業できますか？最悪のシナリオは（私が思うに）トランクからタグを作成し、必要なコミットをチェリーピックする必要があるということです（一部のコミット/機能はまだ本番稼働の準備ができていないため）。

10 svn  branching  tagging 

私は、役割と責任、特に開発ブランチからトランク（またはメイン）へのマージの責任者に関する「ベストプラクティス」を探しています。基本的に私は自分の大義を助けるための弾薬を探しています。 私が直面していることを説明させてください。私は特定のアプリケーションのリード開発者（所有者）です。私たちの会社は最近、VSS（私のアプリケーションが保存されているVSSデータベースの管理者でした）からTFS（私たちの「運用」チームによって作成された開発ブランチに対する権限しか持っていません）に移行しました。以前の仕事ではTFS管理者でしたので、TFSとMSBuildの使い方を知っています。 使用されている分岐およびマージ戦略に問題はありません（メインブランチ、必要に応じてバグ/プロジェクト開発ブランチが作成され、メインにマージされてからリリースブランチに昇格されます）。私が抱えている問題は次のとおりです。 自分でブランチを作成することはできません。「オペレーション」チームメンバーにブランチを作成させるには、TFSタスクを作成する必要があります。 Mainから開発ブランチにマージできません。「オペレーション」チームメンバーがマージを実行するようにTFSタスクを作成する必要があります。「運用担当者」は開発者である場合とそうでない場合があるため、チームが変更を「踏まない」ことを期待しています。彼がマージしているコードに関する知識はほとんどありません。 開発からMainにマージできません。繰り返しますが、 "ops guy"にマージを実行させるには、彼が正しく実行することを期待して、TFSタスクを作成する必要があります。次に、別のTFSタスクを作成してブランチにマージし、開発者以外がMainにマージすることで発生した問題を解決できるようにします。 MSBuildスクリプトを作成または編集できません。ここでも、MSBuildの新機能である「ops」チームと協力して、最も基本的なビルドタスクのみを実行できるようにする必要があります。（複雑なことは何も忘れてください、またはカスタムタスクを天国で禁止してください）。 MSBuildスクリプトを実行できません。繰り返しますが、「ops」チームだけがこれを行うことができます。 このすべてをオフにするには、通常、要求されたタスクを実行する「オフショア」リソースであるため、早朝に（ブランチ/マージ/ビルド）へのタスクを作成しても、完了しない可能性があります。その夜まで。 これで、リリースブランチを維持する「運用」チームに問題はありません。彼らがしていることはすべて、（基本的に）Mainから最新バージョンを取得し、それをリリースブランチにプロモートすることです。"Main"が安定していて準備ができている限り、リリースブランチは適切です。 私の意見では、テクニカルリード（Iなど）は、トランク（「メイン」）の保守と、開発ブランチとの間のマージを担当する必要があります。チームリーダーには、MSビルドスクリプトを生成して、統合テスト環境にビルドおよびデプロイする機能も必要です。 私のケースを証明するのに役立つベストプラクティスドキュメントを誰かに教えてもらえますか？私が行ったすべての検索で、分岐とマージの手法に関するベストプラクティスのみが判明しました。WHOについての言及では、分岐/マージを実行すべきではありません。

10 version-control  team-foundation-server  branching 

具体的には、DVCSとビルドシステムを統合するツールに取り組んでいますが、「メタ」ツール（コンパイラ、VCS、ビルドシステム、テストランナーなど）を開発している人が直面する課題をイメージしています「ドッグフーディング」を通じて発展したい。 私の質問は、分岐ワークフローを使用したスクラムスタイルのリリースプロセスで、ツールの開発サイクルで新しいバージョンのツールの使用を開始するのはどの時点ですか？ 私は、以下のバランスを取るプロセスを探しています。 常にdevelopツールのバージョンを使用します。変更が組み込まれると、自分の開発が中断されます。 常にmasterツールのバージョンを使用します。ドッグフーディングによって明らかになった問題は、すでにリリースされている問題です。

9 scrum  tools  workflows  branching  dogfooding 

3組のテストスイートがあります。 実行に数時間しかかからない「小さな」スイート 複数時間かかる「中」のスイートで、通常は毎晩（毎晩）実行されます 実行に1週間以上かかる「大きな」スイート 短いテストスイートもたくさんありますが、ここではそれらに焦点を当てません。 現在の方法論は、トランクへの各コミットの前に小さなスイートを実行することです。次に、ミディアムスイートが毎晩実行され、午前中に失敗したことが判明した場合は、昨日のコミットのどれが原因であるかを特定し、そのコミットをロールバックして、テストを再試行します。大規模なスイートでは、同様のプロセスが、毎晩ではなく毎週のみ行われます。 残念ながら、ミディアムスイートはかなり頻繁に失敗します。つまり、トランクが不安定になることがよくあります。これは、変更を加えてテストするときに非常に煩わしいことです。トランクからチェックアウトするとき、それが安定していることを確実に知ることができず、テストが失敗した場合、それが私のせいかどうかを確実に知ることができないので、それは迷惑です。 私の質問は、トランクを常に最高の状態に保つような方法でこれらの種類の状況を処理するためのいくつかの既知の方法論がありますか？例：「特別な事前コミットブランチにコミットし、夜間が経過するたびにトランクを定期的に更新する」。 そして、それがSVNのような集中化されたソース管理システムであるか、gitのような分散型システムであるかは重要ですか？ ちなみに、私は物事を変更する能力が限られているジュニア開発者ですが、私が経験しているこの痛みに対処する方法があるかどうかを理解しようとしています。

9 testing  version-control  development-methodologies  branching 

私は最近、dvcsについて同僚と話し合っていました。これは、私たちのオフィスがTFSからの切り替えを検討し始めているためです（私たちはMSショップです）。その過程で、彼はMercurialを使用しているものの、「ブランチ」または「チェックアウト」コマンドを聞いたことがなく、これらの用語が彼にとってなじみのないものであると彼が言ったので、私は非常に混乱しました。彼がそれらについて知らなかった可能性があるのではないかと考え、dvcsブランチがローカルファイルで「適切に」機能する方法を説明した後、彼はかなり混乱しました。 彼は、TFSのしくみと同様に、「ブランチ」を作成したい場合はクローン作成によって行うので、リポジトリの完全なコピーを持っていると説明しました。これは本当に奇妙に思えましたが、私が認めなければならない利点は、ファイルが別々であるため、2つのブランチを同時に見たり作業したりできることです。 このサイトを検索して、多くのオンラインリソースがこの「クローンからブランチへ」の方法論を宣伝するコメントを見る前にこれが尋ねられたかどうかを確認する際に、ポスターを落胆させました。これは実際にdvcsコミュニティで一般的ですか？そして、この道を行くことの長所と短所は何ですか？一度に複数のブランチを表示する必要がなく、切り替えが高速で、すべてのクローンがディスクをいっぱいにする必要がないため、それを行うことは決してありません。

9 workflows  dvcs  branching 

私は現在、私の会社でsvnからgitへの切り替えの過程にあります（1年後に、人々を説得するために費やしました！）。 これまでのところ、これですべてが良くなりますが、私たちが現在ワークフローに持っている小さなものの1つで、私には適切な同等のものを見つけることができません。 現在、すべての開発者はマスターで作業しています。四半期ごとに、マスターをXxブランチにブランチします。Xxブランチは後で最新のリリースになります。これは、svnリポジトリが次のようになることを意味します。 トランク 枝 3.8 4.1 4.2 ... 実際にはタグを使用しません。 時々、発見された緊急のバグ修正があります。 私たちがそれを行う現在の方法は次のとおりです。 マスターで修正する SVNは、関連するコミットの範囲を関連するブランチにマージします（おそらく、最新のリリースなど）。 私たちは宇宙産業にいるので、支社は長命であり、顧客のアップグレードプロセスはかなり長いので、これまでのところ、そのように取り組んできました。 さて、gitでどのようにして良い同等物でしょうか？ これまでのところ、マスターから生成されたブランチのバグを修正してから、このブランチをマスターと4.3にマージしました（たとえば）。ことは、ホットフィックスブランチにはマスター履歴が含まれており、マスターと4.3の間のすべてのコミットもマージされるためですが、これは不要です。 これまでに考えたこと： 私は非常に成功したGitワークフローメソッドを見てきましたが、それらの解決策は、リリースブランチのバグを修正して、逆にマージするのではなく、マージすることです。これは私たちのケースではうまくいくかもしれませんが、実際にバグを修正する前に、バグを修正したい最も古いブランチをすでに知っている必要があるため、かなり面倒です。 もう1つの解決策は、マスターで修正してからコミットを選択することです（今日のsvnマージの場合と同様）。ここでの厄介なことは、この場合、チェリーピックが新しいコミットのように見え、関係が失われるため、マージされたものの履歴がどこで失われるかということです。 それを行うための「良い」方法は何ですか？履歴のコミットを修正するか、チェリーピックを使用して、マージされたものや他の何かを手動で追跡する必要がありますか？ gitでの制作経験がほとんどない場合、私は何かを見逃している可能性があります。

9 git  svn  branching 

私はGitの分岐とタグ付けのベストプラクティスとgitタグ付けのコメント-ベストプラクティスを読みましたが、長い間疑問に思っていたものに対する直接的な回答がありません。 Gitにタグがあるのはなぜですか？（枝だけではなく） 彼らは二流の市民、または少なくとも「異なる」ようです。明示的に指定しない限り、プッシュされません。リモートタグを削除しても、ダウンストリームレポジトリは削除されません。 この最後のポイントは最近問題になりました。誰かが別のリポジトリからの大量のコミットで大量のガベージタグをプッシュしたためです。上流でそれらを削除してコミットをgit push --tagsGCすることもできますが、それは反映されず、次に誰かがでタグをプッシュしたときに、それらのガベージタグとコミットを再プッシュします。そのため、全員が削除したことを確認する必要がありました。 いつ、なぜブランチではなくタグを使用するのですか？

8 git  branching  tagging 

今月から新しいプロジェクトを開始します。プロジェクトは1年間で、本番環境への展開はプロジェクトの終わり頃にのみ行われます。 反復的な開発（反復ごとに1か月）を行うため、これは、QAテストの各反復の終わりに機能をテスト環境にドロップすることを意味します。 私たちの分岐戦略は： トランク-すべての開発はトランクで行われます。 機能の分岐-トランクから分岐すると、大きな機能を開発するために必要に応じて作成され、トランクで実行すると壊れる可能性があります。 QAリリースブランチ-各反復の最後に、トランクのブランチが作成されます。このブランチ（バージョン番号を含む）は、テスト環境にリリースされます。このバージョンで発見されたすべての重大なブロッキングバグはこのブランチで修正され、修正はトランクにマージする必要があります。新しいリリースブランチがトランクから作成される次の反復の終了後にQAリリースブランチが破棄されるため、重大ではない/重要でないバグはQAリリースブランチでは対処されず、トランクでのみ修正されます。 本番ブランチ-これは、プロジェクト終了時の最新のQAリリースブランチになります。これはタグ付けされ、すべての製品バグ修正はこのブランチにあり、トランクにマージされます。 これは正しい分岐戦略ですか？他に検討し損なったことはありますか？ SVNを使用しています。

8 version-control  branching 

ジョエル・スポルスキーの水銀の紹介を読んでいたとき、それは私を襲った： 「そして今、彼らがしていることは次のとおりです。各新機能は大きな#ifdefブロックにあります。そのため、1つのトランクで機能できますが、デバッグされるまで新しいコードが表示されることはありません。正直なところ、それはばかげています。」 なぜこれはとにかくばかげているのですか？これは、他に何もないにしても、単純に処理するのが簡単ではないですか？それは派手なことではありませんが、トリックを行います-少なくともあなたがすでにSubversionと「結婚」している場合。 欠点は何ですか？私は議論を理解していません。

8 svn  mercurial  branching