SubversionでGit Flowを使用する際の障害
私の職場のチームは、VCSとしてSubversionを使用して新しいプロジェクトを開始しています（この質問の目的のために、これは固いものと考えることができます）。私たちはまだプロジェクトの初期段階にあり、分岐モデルについて合意しようとしています。以前のプロジェクトは、非標準バージョンモデルに基づいていたため、既存のリリースのホットフィックスとパッチを管理するときに問題が発生しました。
さまざまな分岐モデルがかなり複雑であることがわかりましたが、かなり明確に理解しているモデルの1つは git flow です。これのバリエーションをSubversionに実装するのがどれほど難しい/望ましくないか知りたいです。明らかに、ブランチで共同作業する人々の点でいくつかの違いがあります。機能ブランチはローカルリポジトリに限定するのではなく一元化する必要がありますが、モデルの他の概念は私が理解しているようにSubversionで再現可能でなければなりません。
このアプローチの欠点または課題は何でしょうか。私が聞いたのは、SVNではGitに比べて「マージは高価です」ということです。しかし、これが実際に何を意味するのか、それがブランチモデルのようなgitフローを使用する能力にどのように影響するのかについては、完全には明確ではありません。
このアプローチの最大の懸念は何でしょう。 Subversionでより自然な同様の明確なアプローチはありますか？
Gitflowは、ソースコードのバージョン管理と分岐のベストプラクティスに基づいています。これに関する非常に良い記事は Advanced SCM Branching Strategies です。
リンクされた記事でヴァンスが述べている点は、ブランチごとに役割が異なるということです。彼は次の役割を特定します。
- メインライン（ここからのすべてのブランチ）
- 開発（開発作業が行われる場合）
- メンテナンス（メンテナンス作業を行う場所）
- 蓄積（リリース準備のために物事をまとめる）
- パッケージ化（リリース用のビルドのパッケージ化）
Gitflowでは、これらは次のとおりです。
- 発展させる
- 機能ブランチ
- 修正プログラムのブランチ
- ブランチをリリースする
- 主人
分岐に関する記事は、Perforceを念頭に置いて書かれました。 PERFORCEは集中管理されたVCSであり、svnと同じです。彼が説明する分岐のパターンは、svnに完全に対応しています。
理解するための鍵は、gitflowがどのようにsvnに移植されるかではなく、分岐の同じ基本概念と分岐の役割を異なるVCS構造に適用する方法です。
私は強く記事を読むことをお勧めします、私はそれに多くの信用をすることができません。そこに記載されている方法は、svnを簡単にマッピングできると思われるトランク/メインラインビルドの哲学に基づいています。