참고 : 내 질문은 내 특정 문제 (Liferay 포함)에 중점을두고 있지만 git에서 동일한 프로젝트의 다양한 버전을 유지 해야하는 모든 사람에게 유용 할 수 있기를 바랍니다.

Liferay Portal 용 플러그인을 많이 작성하는 회사에서 일하고 있습니다. 이러한 플러그인 (포틀릿, 테마 등)은 일반적으로 재사용 가능하며 물론 새 버전의 포털에 대해 업데이트해야합니다.

그러나, 마이그레이션을 가지고 우리가 말을 Liferay의 새 버전으로 포틀릿 수 있도록 평소 와 이전 버전을 유지하기 위해. 또한 일부 클라이언트에 대해 매우 구체적인 사용자 정의를 작성해야하는 경우가 종종 있습니다. "주 버전"에 추가하는 것은 적합하지 않습니다.

이러한 요구 사항은 작업을 복잡하게하지만 다행히도 일부 단순화를 가정 할 수 있습니다. 예를 들어, 플러그인은 한 번에 한 명의 프로그래머 만 자주 업데이트합니다. 플러그인에 두 개 이상의 기능을 동시에 추가하는 것은 매우 드 rare니다.

이제 우리는 Gitorious 로 이주하고 있습니다. 우리는 그러한 시나리오에 대한 분기 모델을 고안하려고 노력하고 있습니다.

내 모델

내가 제안한 것은 다음과 같습니다.

1. 각 플러그인은 프로젝트 내부에 Gitorious에 자체 저장소가 있습니다. 예를 들어, 새끼 고양이를 표시하기위한 포틀릿 kittens-portlet에는 liferay-portlets프로젝트 내부 에 저장소 가 있습니다 .
2. 새 플러그인을 만들 때는 Liferay 버전에 따라 이름이 지정된 분기 (예 :)에 플러그인을 만드십시오 lf5.2.
3. 플러그인에서 업데이트가 이루어질 때마다 업데이트가 승인되어 프로덕션 환경에 배포되고 플러그인에 버전 (예 lf5.2v1: lf5.2v2등)으로 태그를 지정합니다 . *
4. 플러그인을 Liferay의 새 버전으로 이식해야 할 때마다 최신 버전을 분기합니다 (예 : 분기 작성 lf6.0).
5. 생산이 시작되면 새 지점장은과 같은 태그를받습니다 lf6.0v1.
6. 클라이언트별로 플러그인을 사용자 정의해야 할 때마다 클라이언트 이름으로 분기를 작성합니다 (예 : lf5.2clientcorp클라이언트 "ClientCorp Inc."에 대한 분기 작성 ).

이것은 특이한 모델입니다. master병합되지 않은 분기가 많지 않을 것입니다. 이것이 그러한 모델을 가진 저장소가 다음과 같다고 가정 하는 방법입니다 .

친구는이 시스템이 다소 복잡하고 오류가 발생하기 쉽다는 것을 알게되었습니다. 그는 훌륭하고 인기있는 Vincent Driessen 모델을 제안 했는데,이 모델 은 여전히 ​​관리하고 훈련을 요구하기가 더 어렵다는 것을 알았습니다. 물론 훌륭하고 테스트되었지만 우리 상황에는 너무 복잡해 보입니다.

내 친구의 모델

그런 다음 그는 또 다른 모델을 제안했습니다. Liferay 버전의 각 플러그인에 대해 저장소가 있고 (따라서 a kittens-lf5.2-portlet와 a를 만들기 시작 함 kittens-lf6.0-portlet) 각각은 master분기와 develop분기가 있습니다. 는 master항상 배포 할 준비가 될 것입니다. (아니면 다른 방법으로 주위 될 수 master및 stable의해 제안, 스티브 Losh는 ).

이것은 매우 간단하지만이 시스템이 마음에 들지 않았습니다.

1. 프로젝트에 많은 저장소가 생겨서 Gitorious를 탐색하기가 어려울 수 있습니다.
2. 프로젝트 디렉토리의 이름은 관련이 있습니다. 누군가가 저장소를 kittens-lf6.0-portlet디렉토리에 복제하고 (평소와 같이) 개미로 WAR을 생성하면 WAR 이름도 있습니다 kittens-lf6.0-portlet. 이 포틀릿의 이전 버전 ( kittens-portlet예 : 이름이 지정됨 )은 업그레이드 된 포털에서 다른 (아마도 누락 된) 포틀릿으로 간주됩니다. 약간의주의를 기울이면 피할 수 있지만 피하는 것이 좋습니다.
3. 동일한 플러그인의 다른 버전은 별도로 유지됩니다. 나는 내 마음을 아프게한다 :(
4. kittens-lf6.0-portlet 나는 저장소의 추악한 이름이라고 생각합니다.

나는 두 가지 더 주관적인 점인 두 가지 마지막 요점이 내 의지가없는 주된 이유라고 생각합니다. 그럼에도 불구하고 네 가지 반대 의견이 모두 있습니다.

OTOH, 내 자신의 제안은 나에게 이상해 보이며 숨겨진 버그가 있는지 궁금합니다. OT3rdH git은 매우 강력하고 유연하므로 가능성을 탐색하는 데 부끄러움을 느끼지 않아야한다고 생각합니다.

그래서 나는 묻습니다.

1. 가장 좋은 모델은 무엇입니까? 내 제안? 내 친구의 모델? 현재 전통적인 빈센트 드라이 슨 시스템?
2. 다른 분기 모델을 제안 하시겠습니까?
3. 내 모델이 잘못되었다고 생각하면 왜 그렇게 생각하십니까? 나는 단점과 사각 지대가 무엇인지 배우고 싶습니다.

* 실제로는 커밋에 태그를 지정하는 것을 선호 v1하지만 분명히 git의 태그는 분기에서 범위가 지정되지 않습니다. 즉, 1 v1태그 lf5.2와 다른 태그를 가질 수 없으므로 lf6.0이름을 지정해야합니다 분기. BTW가 맞습니까?

이 글을 올바르게 읽으면 기본적으로 기본 개발 라인과 일회성 편차가 발생하지만 기본 라인으로 다시 병합되지 않으며 메인 라인의 진행이 해당 지점에 적용되지 않습니다. 유일한 차이점은 지점에 기반한 버전에 적합한 버그 수정이 지점에 적용되어야한다는 것입니다.

이제 대답은 일상적인 워크 플로에서 중추되고, 한 지점에서 일하는 개발자 수 또는 변경 횟수는 붉은 청어입니다. 나는 주요 지점 변경으로 인해 버그 수정 업데이트를 얻는 지점을 알고 싶어하는 주된 필요성을 보았습니다.이를 위해 지점과 결합 된 저장소는 모두 한곳에 있기 때문에 더 효율적이라고 생각합니다. 교차 수분이 필요하지 않은 경우 별도의 리포지토리가이를 시행하지만 프로젝트를 이해하는 것처럼 해당 시나리오는 실제 프로젝트와 일치하지 않습니다.

Driessen 모델은 프로젝트가 브랜치를 주요 개발 라인으로 다시 병합해야하는 경우에는 잘 작동하지만 필요하지는 않습니다. 그럼에도 불구하고 라이브 제품을 사용하는 경우 InDevelopment and StableRelease 개념을 유지하는 데 장점이 있다고 생각합니다.

요약하면 프로젝트가 분기 모델과 주요 라인에 대한 Driessen 대시와 잘 작동한다고 생각합니다. 귀하의 마일리지가 다를 수 있습니다; 저는 항상 "실제 릴리스"분기로 바뀌는 "보류 릴리스"분기와 다양한 지점에서 수정과 변경의 교차 수분이 필요한 별도의 "다음 릴리스"로 작업하여 인식이 편향 될 수있었습니다.

각 포틀릿에 자체 저장소가 있다는 사실이 문제가됩니다.하지만 이야기가 완전하지 않을 수도 있습니다. 개인적으로 나는 프로젝트마다 저장소를 만들 것입니다. 프로젝트에는 종종 여러 포틀릿이 있으며 모두 동일한 버전의 Liferay에 대해 동일한 실행으로 빌드됩니다. 각 프로젝트는 다른 버전의 Liferay에 대해 빌드하는 기존 프로젝트의 복제본 일 수 있지만 차이가 너무 큰 경우에만 제품을 분할합니다. Liferay 5.1 및 5.2에 대해 빌드가 작동하면 프로젝트를 분할하지 않습니다. 스크립팅 또는 Maven (또는 둘 다)을 사용하여 모든 것이 작동하도록합니다. 각 제품을 관리하고 빌드 할 수있는 Liferay 버전에 Wiki (또는 Trello)를 사용합니다.

그건 그렇고 : 나는 Java 프로그래머, Maven 전문가, Build 전문가이며 Liferay 및 기타 포털 서버 (IBM WebSphere 및 Glassfish)에 경험이 있습니다.

그러나 이것은 단지 내 € 0.02입니다.