권장 git 저장소 구조화

각각 다른 작업을 수행하는 4 개의 구성 요소를 사용하는 프로젝트가 있습니다.권장 git 저장소 구조화

한 모듈에서 변경 한 사항은 다른 구성 요소에서 변경해야 할 수도 있지만 반드시 그런 것은 아닙니다.
각 개별 모듈에 대해 git 리포지토리를 유지 관리했습니다.

So, Project 
    repo1 -> Component A (PHP) 
    repo2 -> Component B (NodeJS) 
    repo3 -> Component C (NodeJS) 
    repo4 -> Component D (JAVA)

이제 전체 프로젝트에 단일 레포를 사용하는 것이 좋습니다.
그러나 나는 편집 성이 있습니다. 모듈이 크기 나 구조가 커지면 모듈을 단일 repo보다 자체 repo에서 유지하는 것이 좋습니다.

나는 다음과 달성하고자하는 :

이러한 각각의 구성 요소가 다른 서버에있을 것입니다
후크에
용이성 각각의 서버

이 용도로 권장되는 git 구조/워크 플로는 무엇입니까?

_{주 :
전체 코드베이스는 여전히 지역이다.
하위 트리를 사용해 보았습니다. 이제는 다른 구성 요소의 모든 커밋을 유지하는 단일 프로젝트가 있습니다. 하위 트리를 사용한 후에는 별도의 모듈을 별도의 git repo로 분할 할 수 있습니다. (서브 모듈에 대해 notgood things을 들었으므로 아직 시도하지 않았습니다.)}

출처

2013-09-28 0_0

독립적으로 업데이트 할 수있는 독립 프로젝트 인 경우 개별 프로젝트로 유지하십시오. 하위 모듈을 사용하지 말고 하나의 모듈에 혼합하지 마십시오. 독립적으로 개발하십시오.

한 구성 요소에서 다른 구성 요소에 영향을주는 변경 사항이있는 경우이를 처리하기 위해 일종의 API 버전 관리를 사용하십시오. 누군가와 호환되지 않는 변경을 할 때 버전 번호를 업데이트해야합니다. 다른 사람이 아닌 다른 사람이 당기는 경우 즉시 잘못 알 수 있습니다.

그 외에도 독립적 인 프로젝트로 취급하고 각 프로젝트의 최신 버전을 배포하십시오. 저쪽에 그것을 복잡하게 할 필요는별로 없습니다.

서로 밀접하게 연결되어 있고 다른 하나와 독립적으로 존재할 수없는 경우 중요한 변경 사항은 모두 두 개가 함께 업데이트 된 다음 한 개의 큰 저장소에서 개발해야합니다. 일들이 그것이 긴밀하게 연결되어 있다면, 그것을 나누는 것은 의미가 없습니다. 배포 스크립트를 사용하여 하나의 큰 저장소에서 다른 서버로 배포하십시오.

어느 쪽을 선택하든 너무 걱정하지 마십시오. Git에 대한 좋은 점 중 하나는 나중에 잘못했음을 알게되면 저장소를 병합하거나 분할하는 것이 매우 쉽다는 것입니다. 분할 방식을 시도해도 혼란 스럽거나 번거롭다면 하위 트리를 병합하면 단일 통합 저장소가 생깁니다. 통합 접근 방식을 시도하면 너무 커지게됩니까?git filter-branch을 실행하여 하위 구성 요소의 각 하위 디렉토리를 분리하면 몇 개의 독립적 인 저장소가 생깁니다 (이 경우 원본을 그대로두면 이후에 관련성이있는 경우를 대비하여 실제로 전체 통합 기록을 갖게됩니다) .

출처

2013-09-28 07:46:27

권장 git 저장소 구조화

답변

관련 문제