37

私たちはSubversionを使用しており、私のような少数の個人を除いて、Subversionでの分岐とマージの経験はほとんどまたはまったくありません。私のSubversionの経験は、マージとツリーの競合が正確にまれではありませんが、解決するのがそれほど難しくない単純な機能ブランチに限定されています。

それを踏まえて、私は現在のトランクへのコミット方法が私たちのニーズに対して単純に持続不可能であるプロジェクトの管理を支援しています。ローカライズされたチームに機能の分岐とマージを導入し、ある程度の成功を収めました。ただし、単純な機能の分岐では、次のようなすべての質問に答えることができませんでした。

  1. このリリースと後続のリリースのコードを並行して開発するにはどうすればよいですか？
  2. どのコードが安定していると見なされますか？
  3. どの（開発中の）コードが次のリリースに入る予定ですか？
  4. どの（開発中の）コードが次のリリースに入る予定ですか？
  5. テスト、アクセプタンス、または本番環境のコードのバージョンは何ですか？
  6. 同時開発アクティビティを既知の安定したリリースと統合して、バグの導入や不完全な作業を減らすにはどうすればよいですか？
  7. リリースされたコードにホットフィックスを提供するにはどうすればよいですか？
  8. ソース管理から、現在進行中の開発活動をどのようにして知ることができますか？
  9. 活用しながら現在のコードベースを中断することなく、どのように実験または研究開発を行うのですか？

ここで定義されている git-flowは、これらの質問の多くに答えるのに大いに役立つようです。Mercurialでこのメソッドを試しましたが、このメソッドも実装できるようです。残念ながら、この時点でDVCSへの移行はテーブルから外れています。

ただし、Subversionでこのメソッドを模倣する簡単な試みは、多くのマージとツリーの競合で失敗しました。マージオプションとエッジケースは非常に多く、不可解です。

Subversionを使用してgit-flowを実装できますか？その場合、問題のレベルはどれくらいですか？

4

3 に答える 3

33

いわゆる不安定トランク開発方式を採用しています。これは、Subversionの作成者がSubversionを作成するときに念頭に置いていた開発方法でした。シンプルで簡単に実装できます。

  • すべての開発はトランクで行います。したがって、不安定なトランクと呼ばれます。
  • リリースに近づくと、そのリリースのブランチを作成します。アイデアは、並列開発を可能な限り短くするためにブランチを十分に遅くすることですが、現在のリリースで作業する必要がなくなったために一部の開発者が仕事をすることができなくなるほど遅くはありませんが、次のリリース。アジャイルでは、これは通常、引き締めスプリントの直前に行われます。これは通常、リリースが機能を完了したときに行われ、現在はバグを修正しているだけです。
  • リリースはブランチから行われます。ブランチにタグを付けます。必要なパッチがある場合、それらはブランチから実行されます。

これがどのように機能するかについての考えです：

  • リリース1.2で作業していると想像してください。あなたはトランクに取り組んでいます。今、あなたはリリース1.2がリリースされようとしている時期に近づいており、開発者を忙しくさせるのに十分な作業がリリース1.2にありません。リリース用に1.2ブランチを作成します。
  • 現在、リリース1.2で作業している人々は、リリース1.2ブランチに切り替えます。一方、1.3に取り組んでいる開発者はトランクにとどまります。
  • これで、リリース1.2の準備が整いました。ブランチでリリース1.2にタグを付けます。ブランチはトランクにマージされません。トランクはリリース1.3用です。
  • バグが報告されており、リリース1.2.1で修正する必要があります。あなたは1.2ブランチから作業を続けます。1.2.1には新しいブランチは必要ありません。（リリース間でブランチをロックして、それらを純粋に保つことができます。
  • リリース1.3を実行しようとしているときは、プロセスを繰り返します。ブランチ1.3を実行し、1.4の作業をトランクで続行します。

いくつかのマージがあります。これは主に、リリースブランチで修正された欠陥をトランクにマージすることです。これを行うには3つのオプションがあります。

  • リリースを実行したら、ブランチ上のすべての変更をトランクにマージします。追跡はほとんどありません。ブランチのすべてのバグ修正がトランクにも適用されると想定しているだけです。
  • 問題が複数のリリースで発生する可能性があることを理解している追跡システムを使用します。この場合、ブランチからトランクで発見されたバグにもマークを付けるだけです。問題追跡システムのおかげで、トランクに適用される変更をチェリーピックできます。
  • 一部のサイトは単にマージされません。また、ブランチに適用されたトランクに適用する必要のある欠陥追跡システムの変更を介して追跡し、単にそれらを再実装します。ブランチからトランクに変更をコピーする場合がありますが、正式なマージは行われません。ただし、これを行うと、マージすることはできません（--record-onlyフラグとマージしない限り）。

もちろん、この方法には計画と呼ばれるものが必要であることに気づきます。開発者が将来のリリースで作業する前に次のリリースの作業を行うように、作業に優先順位を付ける必要があります。すべての開発者を忙しくさせるのに十分な作業が次のリリースでなくなった場合にのみ、分岐します。

開発者または問題ごとに個別の開発ブランチを使用し、それらの変更をトランクに配信する標準のGitワークフローを実装できます。これには、開発者/機能ごとに1つずつ、多くのブランチが必要になります。

まず、トランクからブランチにマージして、コードをリベースします。リベースが完了したら、--reintegrateスイッチを使用してブランチからトランクにマージします。--reintegrate1.6より前では、マージトラッキングが混乱していたため、ブランチを削除して再作成することになっていました。ただし、これはリリース1.6.x以降で修正されています。

于 2012-11-12T19:29:57.693 に答える
2

それは大きな質問です。私はいくつかの問題を解決する方法のアイデアしか持っていません：

  1. ブランチをあまり使わないと、これは簡単には解決できないと思います。これがGITを使用しても簡単に解決できるかどうかはわかりません。機能ブランチはこの問題の解決に大いに役立ちますが、一般的には、次のリリースの機能のみに集中するようにしてください。
  2. trunk-masterブランチだと思います。
  3. developmentブランチは次のリリースのコードだと思います
  4. 多くのブランチを使用しないと難しいようです。これを適切に解決する方法がわかりません。
  5. ブランチを使用するか、TESTおよびACCにあるリビジョン番号をメモすることができます。PRODは私が推測するタグに入れる必要があります。
  6. 自動回帰テストと継続的インテグレーションを使用すると思います。また、ピアレビューを使用すると、ここで役立ちます。せいぜい、ある種のツールを使用して、ファイルをレビュー済みとしてマークします。そうすれば、レビュー済みのファイルのみをマージすることができます。また、コミットメッセージをバグトラッカーに関連付けて、どの問題に関連してどのファイルが変更されたかを自動的に把握し、マージするファイルのすべての問題が実際に閉じられていることを確認することも興味深い場合があります。これは、特にブランチの一部のみをマージすることを考えている場合は、簡単な作業ではありません。これにより、機能のマージを実行します。
  7. リリースのタグを使用します。ブランチのようにチェックアウトして、必要に応じてパッチを追加できます
  8. リポジトリ全体のすべてのsvnコミットを1ページに一覧表示します（例：trac / redmine / jiraの概要）
  9. 恐れているローカルコピー/またはブランチを再度使用してください。または、研究開発でgitsvnをローカルで使用するようにします。

これらの問題のいくつかは、少なくとも部分的には、を使用して解決できgit svnます。これを使用することで、たとえば、グローバルリポジトリに保存せずに、gitsブランチ機能を使用してローカルで実験することができます。もちろん、チームに多くのメンバーがいる新機能を検討している場合、すべてのメンバーがgitの使用とネットワークを介した相互のプルに慣れていない限り、これは興味深いことではありません。を使用git svnすることで、git cherrypick単一のコミットを手動で選択して、あるブランチから別のブランチに適用することもできます（たとえば、released-xx-tagへの開発）。

今のところ思いつくのはこれだけです。お役に立てば幸いです。

于 2012-11-12T15:09:15.587 に答える
1

私の活動では、次のアプローチでSVNを使用しています。

  1. トランクは「マスター」ブランチです。トランクに直接何かをコミットしないでください。トランクは常に、本番環境でリリースされた最新バージョンと正確に一致する必要があります。したがって、トランクは常に安定したブランチを表します。トランクは、ブランチの再統合によってのみ更新されます。

  2. あなたはあなたの仕事のために枝が必要です。すべての新しいブランチはトランクから作成する必要があるため、すべての新しいブランチは作成時に本番バージョンと正確に一致します。変更と修正はブランチでコミットされます。

  3. 少なくとも2つのメインブランチが必要です。

    • 開発：まだリリースが計画されていない将来の開発を対象としています。
    • ホットフィックス：すべてのバグ修正と修正のみをコミットするために使用されます。頻繁に使用する場合は、トランクの更新時にトランクバージョンで更新する必要があります。

  4. プロジェクト、サブプロジェクト、変更要求など、作業のメインストリームごとにブランチを作成します。並行開発で作業できます。

  5. 「統合」ブランチを作成して、解放する必要のあるブランチを結合します。リリースの候補となるすべてのブランチを統合ブランチにマージする必要があります。したがって、統合ブランチは、たとえば、修正プログラムとプロジェクトの両方に参加できます。

  6. 統合ブランチまたはブランチ自体からアーティファクトを構築します。

  7. ブランチをリリースしたら、そのリリースのタグを作成します。これにより、リリースされたバージョンのコピーを作成しても、ブランチを操作できます。タグでは、リリースされたバージョンのみが必要です。タグの変更をコミットしないでください！

  8. ブランチが解放されたら、トランクを更新する必要があります。したがって、トランク内のブランチを再統合します。統合ブランチを再統合することも、ブランチを直接再統合することもできます（統合からパスしなかった場合）。

  9. トランクが再び本番バージョンと一致したら、アクティブなすべてのブランチで報告します。

このメソッドは、実際にはgit-flowの概念のレプリカではありませんが、いくつかの要件に従います。

このアプローチでは、次の利点があります。

  • トランクは安定しています。あなたは常にその瞬間にトランクが何を表しているかを知っています。

  • すべてのブランチには、独自の変更のみが含まれています。

  • 統合ブランチを使用すると、単一のリリースで並列ブランチを管理できます

  • タグを使用すると、リリースされたバージョンのコピーが常にあります

欠点は次のとおりです。

  • 管理する多くのブランチ。

  • 統合ブランチに変更を報告するために、特に頻繁にマージして切り替える必要があります

  • 毎回解決すべき多くの対立

ちなみに、これはバージョンの制御を維持できるため、私がこれまでに取り組んだ中で最高のアプローチです。

于 2018-05-26T00:13:13.167 に答える