소스 컨트롤 브랜칭에 대한 다른 접근법

Question

소스 컨트롤을 사용할 때, 내가 익숙하게 사용하는 방법은 트렁크에서 개발 한 다음 QA로 옮기기 바로 전에 트렁크를 분기하는 것입니다.

저는 부서의 다른 사람들과 이야기를 나누었습니다. 분명히 다른 작업 방식에 대한 열정적 인 견해가 있습니다. 개발주기 초반부에 새로운 지점을 만들고, 분기를 선택한 다음 끝에있는 트렁크로 다시 병합하십시오. 이 방법에 대한 아이디어는 트렁크를 깨끗하게 유지하는 것입니다.

한 제안자가 후자의 접근 방식을 "표준"접근 방식이라고 주장하는 것에 대해 매우 회의적이지만 (나는 다르게 말하면 기쁘지만), 나는 그것이 상당히 일반적이라는 말을 듣지 않을 것입니다. 어떤 이점을 상상할 수 있습니다 (어떤 기능이나 기능 집합을 언제 배포 할 것인지 선택하는 것이 더 쉽습니다). 그러나 모든 단점이 트렁크에 다시 병합되어야하므로 잠재적 인 병합 문제가 있습니다.

몇 가지 후속 연구를이 발견 http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx

는 또한 사람들이 사용하고있는 다른 방법에 대한 이러한 접근 방법의 상대적 강점과 약점에 대한 감각이있는 사람들로부터 듣고 호기심 것인가를.

Answer 1

이이 이전 SO 항목에 매우 유사 질문 :

Subversion - should anyone be developing off the trunk?

정확히 동일하지 않습니다,하지만 응답에서 많은 개념은 동일합니다.

개인 의견 : 트렁크는 활발한 개발을위한 것입니다. "pristine"을 유지하려는 이전 버전의 개발 라인은 버전 브랜치 (및 릴리스 용 태그)에 있어야합니다. 능동적 인 개발이 트렁크에 있더라도 "트렁크는 항상 컴파일해야합니다"라고 계속 유지하려고 할 수 있습니다.

Answer 2

같은 팀에서 일하는 팀이 트렁크에서 작업하고 출시하기 전에 지점을 만드는 것은 좋은 접근 방식입니다. 병합을 최소화하고, 패치를해야하거나 어떤 이유로 되돌아 가야하는 경우 모든 릴리스에 대해 고유 한 분기를 갖습니다.

그러나 여러 팀이 별도의 작업을 수행 할 때 트렁크에서 충돌이 발생하므로 작동하지 않습니다. 나는 그것에 대해 많은 경험이 없으므로 나는 그 주위의 몇 가지 아이디어를 고대하고있다. 한 가지 접근법은 아마도 각 팀마다 하나씩 여러 개의 분기를 갖는 것이고, 그런 다음 트렁크의 릴리스로 이동하는 분기를 병합하는 것입니다. (나는 단지 좌절감을 상상할 수있다) :

Answer 3

트렁크를 청결하게 유지하는 것이 좋다. 이것은 언제든지 작업중인 버전을 컴파일하고, 베타 버전을 배포하고, 베타 버전을 만들어 데모 버전을 생성 할 수있게 해줍니다 ...

변경 사항은 별도의 분기에서 수행됩니다. 이것은 더 나은 추적 성을 제공하며, 분기의 소스 컨트롤을 활용하고 임시 버전을 체크인 할 수 있습니다. 이상적인 세계에서 병합 문제는 [자동] 테스트에서 다룹니다. 변경 사항을 트렁크에 통합하는 것이 빠를수록 좋습니다.

누군가가 속도를 늦추므로 테스트하지 않은 코드를 트렁크에 올려 놓지 마십시오.