Subversion에서 Git Flow 사용에 대한 장애

우리 팀은 Subversion을 VCS로 사용하여 새로운 프로젝트를 시작하고 있습니다 (이 질문의 목적을 위해이 세트를 돌로 고려할 수 있습니다). 우리는 여전히 프로젝트 초기 단계에 있으며 브랜칭 모델에 동의하려고 노력하고 있습니다. 이전 프로젝트는 비표준 버전 모델을 기반으로했으며 기존 릴리스에 대한 핫픽스 및 패치를 관리 할 때 문제가 발생했습니다.

다른 분기 모델이 다소 복잡하다는 것을 알았지 만 상당히 명확하게 이해하는 모델은 git flow 입니다. Subversion 에서이 변형을 구현하는 것이 얼마나 어렵고 바람직하지 않은지 궁금합니다. 분명히 브랜치에서 협업하는 사람들의 관점에서 약간의 차이가있을 것입니다. 기능 브랜치는 로컬 리포지토리에 국한되지 않고 중앙 집중식이어야하지만 모델의 다른 개념은 Subversion에서 재현 할 수 있어야합니다.

이 접근법의 단점 또는 문제점은 무엇입니까? 내가 들었던 것은 SVN에서 Git에 비해 "합병이 비싸다"는 것입니다. 그러나 이것이 실제로 무엇을 의미하는지 또는 브랜칭 모델과 같은 git flow를 사용하는 우리의 능력에 어떤 영향을 미치는지에 대해서는 명확하지 않습니다.

이 접근법의 가장 큰 관심사는 무엇입니까? Subversion에서 더 자연스럽고 비슷한 접근법이 있습니까?

Gitflow는 소스 코드 버전 관리 및 분기의 모범 사례를 기반으로합니다. 이것에 대한 아주 좋은 기사는 Advanced SCM Branching Strategies입니다.

Vance가 링크 된 기사에서하는 요점은 다른 브랜치가 다른 역할을 한다는 것 입니다. 그는 다음의 역할을 식별합니다.

1. 메인 라인 (여기에서 모든 지점)
2. 개발 (개발 작업이 완료된 곳)
3. 유지 보수 (유지 보수 작업이 수행되는 위치)
4. 축적 (해제 준비를 위해 물건을 가져 오기)
5. 패키징 (릴리스 빌드 빌드)

gitflow에서 이들은 다음과 같습니다.

1. 나타나게 하다
2. 기능 지점
3. 핫픽스 브랜치
4. 릴리스 지점
5. 석사

분기에 관한 기사는 Perforce를 염두에두고 작성되었습니다. Perforce는 svn과 마찬가지로 중앙 집중식 VCS입니다. 그가 묘사하는 가지의 패턴은 svn에 완벽하게 매핑됩니다.

gitflow가 어떻게 svn으로 포팅되는지가 아니라 동일한 기본 브랜칭 개념과 브랜치의 역할을 다른 VCS 구조에 적용하는 방법을 알아야합니다.

나는 것 강하게 나는 그것을 더 신용 할 수 없어, 기사를 읽어 보시기 바랍니다. 여기에 설명 된 방식은 svn에 쉽게 매핑 할 수있는 트렁크 / 메인 라인 빌드 철학을 기반으로합니다.