Subversionでgit-flowモデルを使用することは可能ですか？
私たちはSubversionを使用しており、私のような少数の個人を除いて、Subversionでの分岐とマージの経験はほとんどまたはまったくありません。私のSubversionの経験は、マージとツリーの競合が正確にまれではありませんが、解決するのがそれほど難しくない単純な機能ブランチに限定されています。
それを踏まえて、私は現在のトランクへのコミット方法が私たちのニーズに対して単純に持続不可能であるプロジェクトの管理を支援しています。ローカライズされたチームに機能の分岐とマージを導入し、ある程度の成功を収めました。ただし、単純な機能の分岐では、次のようなすべての質問に答えることができませんでした。
- このリリースと後続のリリースのコードを並行して開発するにはどうすればよいですか？
- どのコードが安定していると見なされますか？
- どの（開発中の）コードが次のリリースに入る予定ですか？
- どの（開発中の）コードが次のリリースに入る予定ですか？
- テスト、受け入れ、または本番環境のコードのバージョンは何ですか？
- 同時開発アクティビティを既知の安定したリリースと統合して、バグの導入や不完全な作業を減らすにはどうすればよいですか？
- リリースされたコードにホットフィックスを提供するにはどうすればよいですか？
- ソース管理から、現在進行中の開発活動をどのようにして知ることができますか？
- 活用しながら現在のコードベースを中断することなく、どのように実験または研究開発を行うのですか？
ここで定義されているgit-flow は、これらの質問の多くに答えるのに大いに役立つようです。 Mercurialでこのメソッドを試しましたが、そこでもこのメソッドを実装できるようです。残念ながら、DVCSへの移行はこの時点ではテーブルから外れています。
しかし、Subversionでこのメソッドを模倣する私の短い試みは、多くのマージとツリーの競合で失敗しました。マージオプションとエッジケースは非常に多く、不可解です。
Subversionを使用して git-flow を実装できますか？その場合、痛みのレベルはどれくらいですか？
nstableトランク開発メソッドと呼ばれるものを使用します。これは、Subversionの作成者がSubversionを作成したときに念頭に置いていた開発方法でした。シンプルで実装も簡単です。
- すべての開発はtrunkで行います。したがって、不安定と呼ばれますトランク。
- リリースに近づくと、そのリリースのブランチを作成します。アイデアは、並列開発をできるだけ短くするためにブランチを十分に遅くすることですが、現在のリリースで作業する必要がなくなったために一部の開発者が仕事をすることができないほど遅くはありませんが、次のリリース。アジャイルでは、これは通常firming sprintの直前に行われます。これは通常、リリースが機能を完了したときに行われ、現在はバグを修正しているだけです。
- リリースはブランチから行われます。ブランチにタグを付けます。必要なパッチがある場合、それらはブランチから実行されます。
これがどのように機能するかについての考えです：
- リリース1.2で作業していると想像してください。あなたはトランクに取り組んでいます。今、あなたはリリース1.2がリリースされようとしている時期に近づいており、開発者を忙しくさせるのに十分な作業がリリース1.2にありません。リリース用に1.2ブランチを作成します。
- 現在、リリース1.2に取り組んでいる人々は、リリース1.2ブランチに切り替えています。一方、1.3に取り組んでいる開発者はtrunkにとどまります。
- これで、リリース1.2の準備が整いました。ブランチでリリース1.2にタグを付けます。ブランチはトランクにマージされません。トランクはリリース1.3用です。
- バグが報告されており、リリース1.2.1で修正する必要があります。あなたは1.2ブランチから作業を続けます。 1.2.1では新しいブランチは必要ありません。 （リリース間でブランチをロックして、それらを保持することができます純粋。
- リリース1.3を実行しようとしているときは、プロセスを繰り返します。ブランチ1.3を実行すると、トランクで1.4の作業が続行されます。
いくつかのマージがあります。これは主に、リリースブランチで修正された欠陥をトランクにマージすることです。これを行うには3つのオプションがあります。
- リリースを行ったら、ブランチ上のすべての変更をマージしてトランクに戻します。追跡はほとんどありません。ブランチのすべてのバグ修正がトランクにも適用されると想定しているだけです。
- 問題が複数のリリースで発生する可能性があることを理解している追跡システムを使用します。この場合、ブランチからトランクで発見されたバグにもマークを付けるだけです。問題追跡システムのおかげで、トランクに適用される変更をチェリーピックできます。
- 一部のサイトは単にマージされません。また、ブランチに適用されたトランクに適用する必要のある変更を欠陥追跡システムを介して追跡し、単にそれらを再実装します。ブランチからトランクに変更をコピーする場合がありますが、正式なマージは行いません。ただし、これを実行すると、マージすることはできません（
--record-onlyフラグを使用してマージしない限り）。
もちろん、このメソッドはplanningと呼ばれるものを使用することに気づきます。開発者が将来のリリースで作業する前に次のリリースの作業を行うように、作業に優先順位を付ける必要があります。次のリリースですべての開発者を忙しくさせるのに十分な作業がなくなった場合にのみ、分岐します。
開発者または問題ごとに開発用の個別の開発ブランチを使用する標準のGitワークフローを実装してから、それらの変更をトランクに配信実装できます。これには、開発者/機能ごとに1つずつ、多くのブランチが必要になります。
最初にトランクからブランチにマージしてrebaseコードにマージします。リベースが完了したら、--reintegrateスイッチを使用してブランチからトランクにマージします。 1.6より前では、--reintegrateがマージ追跡を台無しにしたため、ブランチを削除して再作成することになっていた。ただし、これはリリース1.6.x以降で修正されています。
それは大きな質問です。私はいくつかの問題を解決する方法のアイデアしか持っていません：
- ブランチをあまり使わないと、これは簡単には解決できないと思います。これがGITを使用しても簡単に解決できるかどうかはわかりません。機能ブランチはこの問題の解決に大いに役立ちますが、一般的には、次のリリースの機能のみに集中するようにしてください。
trunk-私はそれをmasterブランチと考えています。developmentブランチは次のリリースのコードだと思います- 多くのブランチを使用しないと難しいようです。これを適切に解決する方法がわかりません。
- ブランチを使用するか、TESTおよびACCにあるリビジョン番号をメモすることができます。 PRODは私が推測するタグに入れる必要があります。
- 自動回帰テストと継続的インテグレーションを使用すると思います。また、ピアレビューを使用すると、ここで役立ちます。せいぜい、何らかのツールを使用してファイルをレビュー済みとしてマークします。そうすれば、レビュー済みのファイルのみをマージすることができます。コミットメッセージをバグトラッカーに結び付けて、どの問題に関連してどのファイルが変更されたかを自動的に把握し、マージするファイルのすべての問題が実際に閉じられていることを確認することも興味深いかもしれません。これは、特にブランチの一部のみをマージすることを考えている場合は、簡単な作業ではありません。これにより、機能のマージを実行します。
- リリースのタグを使用します。ブランチのようにチェックアウトして、必要に応じてパッチを追加できます
- リポジトリ全体のすべてのsvnコミットを1つのページに一覧表示します（例：trac/redmine/jiraの概要）
- 私が恐れているローカルコピー/またはブランチをもう一度使用してください。または、研究開発でgitsvnをローカルで使用して研究を行ってください。
これらの問題のいくつかは、少なくとも部分的には、git svnを使用することで解決できます。これを使用することで、たとえば、グローバルリポジトリに保存せずに、gitsブランチ機能を使用してローカルで実験することができます。もちろん、チームに多くのメンバーがいる新機能を検討している場合、すべてのメンバーがgitの使用とネットワークを介した相互のプルに慣れていない限り、これは興味深いことではありません。 git svnを使用することで、git cherrypickを使用して、1つのブランチから別のブランチに適用する単一のコミットを手動で選択することもできます（例：released-x.x-tagへの開発）。
今のところ思いつくのはこれだけです。お役に立てば幸いです。
私の活動では、次のアプローチでSVNを使用しています。
トランクは「マスター」ブランチです。トランクに直接何かをコミットしないでください。トランクは常に、本番環境でリリースされた最新バージョンと正確に一致する必要があります。したがって、トランクは常に安定したブランチを表します。トランクは、ブランチの再統合によってのみ更新されます。
あなたはあなたの仕事のために枝が必要です。すべての新しいブランチはトランクから作成する必要があるため、すべての新しいブランチは作成時に本番バージョンと正確に一致します。変更と修正はブランチでコミットされます。
少なくとも2つのメインブランチが必要です。
- 開発：まだリリースが計画されていない将来の開発を対象としています。
- ホットフィックス：すべてのバグ修正と修正のみをコミットするために使用されます。頻繁に使用する場合は、トランクの更新時にトランクバージョンで更新する必要があります。
プロジェクト、サブプロジェクト、変更要求など、作業のメインストリームごとにブランチを作成します。並行開発で作業できます。
「統合」ブランチを作成して、リリースする必要のあるブランチを結合します。リリースの候補となるすべてのブランチを統合ブランチにマージする必要があります。したがって、統合ブランチは、たとえば、修正プログラムとプロジェクトの両方に参加できます。
統合ブランチまたはブランチ自体からアーティファクトを構築します。
ブランチをリリースしたら、そのリリースのタグを作成します。これにより、リリースされたバージョンのコピーを作成しても、ブランチを操作できます。タグでは、リリースされたバージョンのみが必要です。タグの変更をコミットしないでください！
ブランチが解放されたら、トランクを更新する必要があります。したがって、トランク内のブランチを再統合します。統合ブランチを再統合することも、ブランチを直接再統合することもできます（統合からパスしなかった場合）。
トランクが再び製品バージョンと一致したら、アクティブなすべてのブランチで報告します。
このメソッドは、実際にはgit-flowの概念のレプリカではありませんが、いくつかの要件に従います。
このアプローチでは、次の利点があります。
トランクは安定しています。あなたはいつもその瞬間にトランクが何を表しているかを知っています。
すべてのブランチには、独自の変更のみが含まれています。
統合ブランチを使用すると、単一のリリースで並列ブランチを管理できます
タグを使用すると、リリースされたバージョンのコピーが常にあります
欠点は次のとおりです。
管理する多くのブランチ。
統合ブランチへの変更を報告するために、特に頻繁にマージして切り替える必要があります
毎回解決すべき多くの対立
ちなみに、これはバージョンの制御を維持できるため、これまでに使用した中で最高のアプローチです。