큰 프로젝트 레이아웃 : 여러 하위 프로젝트에 새로운 기능 추가

버전 관리 관리 시스템으로 많은 구성 요소로 큰 프로젝트를 관리하는 방법을 알고 싶습니다.

현재 프로젝트에는 4 가지 주요 부분이 있습니다.

1. 편물
2. 섬기는 사람
3. 관리 콘솔
4. 플랫폼.

웹 및 서버 부분은 내가 작성한 2 개의 라이브러리를 사용합니다. 총 5 개의 git 저장소와 1 개의 수은 저장소가 있습니다. 프로젝트 빌드 스크립트는 플랫폼 저장소에 있습니다. 전체 건물 프로세스를 자동화합니다.

문제는 여러 구성 요소에 영향을 미치는 새로운 기능을 추가 할 때 영향을받는 각 리포지토리에 대해 분기를 만들어야합니다. 기능을 구현하십시오. 다시 병합하십시오. 내 직감은 "뭔가 잘못되었습니다"입니다.

단일 저장소를 작성하고 모든 구성 요소를 거기에 배치해야합니까? 이 경우 분기가 더 쉬울 것이라고 생각합니다. 아니면 그냥 내가 지금하고있는 일을 해요. 이 경우 각 리포지토리에 분기를 만드는이 문제를 어떻게 해결합니까?

설명하는 상황에서는 여러 리포지토리를 사용하면 이점이 없지만 비용이 발생합니다. 이전 버전의 리포지토리로 롤백 할 수 없으며 시스템이 계속 작동 할 것이라는 확신이 있습니다. 코드가 리포지토리에 밀접하게 연결되어 있기 때문입니다. 롤백 기능에 대한 확신이 소스 제어의 주요 이점 중 하나이므로 이것이 원하는 상황이 아닙니다.

해결책은 코드 내부의 코드 결합을 기반으로 저장소 구조를 정의하는 것입니다. 프로젝트 컴포넌트 A가 프로젝트 컴포넌트 B와 안정적인 인터페이스 만 공유하는 경우 별도의 저장소에 배치 할 수 있습니다. 그렇지 않으면 동일한 저장소에 함께 배치해야합니다. 보다 세분화 된 리포지토리 레이아웃에는 더 나은 시스템 아키텍처가 반영됩니다.

각 리포지토리가 독립 실행 형 프로젝트 또는 라이브러리 인 경우 프로젝트 전체에서 교차 절단되는 새로운 기능을 추가 할 때 각 리포지토리에서 기능 분기를 만들어야하는 것이 본질적으로 잘못된 것은 없다고 말하고 싶습니다. 독립형이므로 각각 독립적으로 버전을 지정할 수 있으며 이전 API를 더 이상 사용하지 않을 수 있습니다.

그러나 특정 경우 리포지토리가 코드를 효과적으로 그룹화하지 않은 것처럼 들립니다. 한 리포지토리의 코드를 변경해야 다른 리포지토리 (더 이상 사용되지 않음)를 변경 해야하는 경우 커플 링이 너무 빡빡하거나 리포지토리를 재구성해야합니다.

모든 저장소가 실제로 동일한 프로젝트의 일부인 경우 (독립 할 수 없음) 저장소가 하나만 있어야합니다. (또는 2 : 주요 프로젝트 및 일반 / 표준화 된 기능을위한 프로젝트)