버전 관리 소프트웨어의 현재 개발과 유지 관리 개발을 분리하는 데 권장되는 방법은 무엇입니까?

Git을 사용하여 관리되는 소프트웨어 응용 프로그램이 있습니다. 방금 장기적으로 유지할 계획 인 새 버전 2.x를 출시했습니다 (주로 버그 수정). 그동안 버전 3.x 작업을 시작하고 싶습니다. 이를 관리하기 위해 권장되는 방법은 무엇입니까? 버전 2.x에 대한 분기를 작성하고 마스터에서 3.x를 개발해야합니까? 아니면 다른 방법?

매우 흥미로운 일을하는 방법이 여기에 설명되었습니다 : 성공적인 Git 분기 모델

나는 그것이 매우 흥미로운 것을 알았지 만 실제로 그것을 사용하지는 않았습니다.

요청에 따라 기사의 내용에 대한 (매우) 짧은 요약이 있습니다.

• 마스터 지점은 완료된 이정표 (예 : 버전 1.0, 1.1, 1.2 등) 만 나타냅니다.
• 개발은 자체 브랜치에서 수행됩니다 (편의 한 "개발", 누가 생각 했습니까?). 기능 완료 버전이 완료 될 때마다 개발 브랜치가 마스터 브랜치로 다시 병합됩니다.
• 개발에서 분기하는 것은 기능 분기입니다. 이는 다음 (또는 향후) 릴리스에 대한 단일 기능을 나타냅니다. 개발 지점과 다시 병합됩니다.
• 개발에서 나오는 또 다른 지점은 "릴리스"지점입니다. 사소한 세부 사항 만 정리해야하는 거의 완전한 릴리스 버전을 나타내는 지점입니다. 개발 브랜치 및 궁극적으로 마스터 브랜치와 병합
• 릴리스 중 하나에서 심각한 버그가 발견되면 마스터 분기에서 "핫픽스"분기 분기 (예 : "사용시 코나미 코드가 입력되면 프로그램이 기본 하드 드라이브를 다시 포맷합니다 ..."). 버그가있는 릴리스에서 분기되며 수정이 완료되면 마스터 분기와 개발 분기로 다시 병합됩니다.

이 기사는 짧지 만 기사를 자세히 설명하고 유용한 시각화 그래픽을 사용하면 이해하기가 훨씬 쉽다는 것을 믿습니다.

내 원칙은 지점이 짧을수록 지점 구조에 더 깊어 야하고 이름이 더 구체적이어야한다는 것입니다. 가지가 길수록 분기 구조가 얕아지고 이름이 더 일반적입니다.

따라서 장기 (3.X) 버전의 마스터를 유지하고 특정 브랜치 (릴리스 코드 이름 또는 더 나쁜 릴리스 번호)가 아닌 일반적인 이름 (마스터, 트렁크, 디벨 등) 으로이 브랜치를 명명하십시오. 늦은 마케팅 결정에 실제로 너무 의존하는 경우)

분기에 대한 평평한 이름 공간이 있고 분기가 동등한 git과 같은 시스템에서는 그다지 중요하지 않습니다. 브랜치에 대한 계층 네임 스페이스가있는 클리어 케이스와 같은 시스템에서 더 중요합니다 (V4 브랜치의 전체 이름은 결국 main / v1 / v2 / v3 / v4 ...)입니다.