여러 릴리즈를 유지하기위한 git 브랜칭

Question

프로젝트에서 git repo에서 브랜치를 관리하는 방법을 고려 중입니다. 나는 famous article을 읽었으며 실제로 아이디어가 마음에 들었습니다.이 모델이 우리에게 유용 할 것 같습니다.

그러나 여기에는 master 분기의 존재에서 비롯된 숨겨진 가정이 있습니다. 후자의 릴리스에서는 버전이 커졌습니다. 예를 들어 2.0.1은 항상 1.5.10 이후에 출시됩니다. 따라서 마스터에서 각 커밋을 트래버스하면 버전이 항상 증가합니다.

이것은 우리 프로젝트의 경우에 해당하지 않습니다. 다른 고객을 위해 여러 버전을 유지해야합니다. 버전 1.5에 대해 지원해야하는 고객 (수정본 제공)은 다른 고객의 경우 2.0입니다. 분명히 버전 1.5.10은 버전 2.0.1보다 늦을 수 있습니다 (시간 기준). 2.0.1이 커밋 된 후에 1.5.10을 master에 적용하면 의미가 없습니다.

기사의 모델이 우리에게 적합하지 않습니까? 아니면 작동시키기 위해 조금 수정할 수 있습니까?

Answer 1

마스터는 현재 버전을 반영해야합니다. 즉, 구현 한 방식입니다. 다른 버전은 온 분기에 있습니다. 지점 V1 마스터 역사의 더 이상 일부가 아닙니다 및 V2의 역사는 마스터와 합병 한에 예컨대

V1 (master) -> -> -> \/ -> V2 (master) 
    v2 -> -> -> -> /\ -> V1 (no longer master) 

은 커밋합니다. 따라서 로그에 기록이 충돌하지 않아야합니다.

Answer 2

대응하는 메이저 릴리스에 대해 상이한 브랜치를 갖는 것이 잘 알려져있다.

master은 여전히 ​​주요 통합 분기로 표시됩니다.

릴리스 지점을 별도로 유지 관리해야하며 모든 릴리스 지점에 전달할 커밋을 결정해야합니다.

여러분이 알고있는 유명한 프로젝트를 살펴보고 출시 모델을 채택하고 저장소 정책을 배우는 것이 좋습니다. 다음은 git scm을 사용하여 여러 주요 릴리스를 유지 관리하는 좋은 예입니다. https://github.com/django/django/branches