작업중 인 프로젝트를 하나의 저장소가 아닌 두 개의 저장소로 나누는 것이 타당한 지 알고 싶습니다.
내가 말할 수있는 것에서 :
- 프론트 엔드는 html + js로 작성됩니다
- .net의 백엔드
- 백엔드는 프론트 엔드에 의존하지 않으며 프론트 엔드는 백엔드에 의존하지 않습니다
- 프론트 엔드는 백엔드에서 구현 된 편안한 API를 사용합니다.
- 프런트 엔드는 모든 정적 http 서버에서 호스팅 될 수 있습니다.
현재 저장소는 다음과 같은 구조를 가지고 있습니다.
뿌리:
- 프론트 엔드 / *
- 백엔드 / *
두 프로젝트를 동일한 저장소에 유지하는 것은 실수라고 생각합니다. 두 프로젝트 모두 서로간에 종속성이 없으므로 개별 리포지토리와 하위 모듈이있는 상위 리포지토리에 속해야합니다.
나는 그것이 무의미하고 우리가 그렇게하면 아무런 이익을 얻지 못할 것이라고 들었습니다.
내 주장 중 일부는 다음과 같습니다.
- 서로 의존하지 않는 두 개의 모듈이 있습니다.
- 두 프로젝트의 소스 히스토리를 장기적으로 보유하면 상황이 복잡해질 수 있습니다 (커밋의 절반은 찾고있는 버그와 전혀 관련이없는 프론트 엔드에서 무언가를 찾기 위해 히스토리를 검색하십시오)
- 충돌 및 병합
- 한 개발자는 백엔드에서만 작업 할 수 있지만 항상 프론트 엔드 또는 다른 방법으로 가져와야합니다.
- 장기적으로는 배포 할시기입니다. 어떤 식 으로든 프런트 엔드는 하나의 백엔드 서버를 사용하면서 여러 정적 서버에 배포 할 수 있습니다. 모든 경우에 사람들은 전체 백엔드를 복제하거나 모든 서버에 프론트 엔드 만 푸시하거나 백엔드를 제거하도록 사용자 정의 스크립트를 작성해야합니다. 하나만 필요한 경우 프런트 엔드 또는 백엔드 만 푸시 / 풀하기 만하면됩니다.
- 반대 주장 (한 사람이 두 프로젝트 모두에서 일할 수 있음), 하위 모듈로 세 번째 저장소를 만들고 함께 개발하십시오. 히스토리는 개별 모듈에서 분리되어 유지되며 백엔드 / 프론트 버전이 실제로 동기화되어 작동하는 태그를 항상 작성할 수 있습니다. 하나의 리포지토리에서 프런트 엔드 / 백엔드를 함께 사용한다고해서 함께 작동한다는 의미는 아닙니다. 두 역사를 하나의 큰 레포로 병합하고 있습니다.
- 프런트 엔드 / 백엔드를 하위 모듈로 사용하면 프로젝트에 프리랜서를 추가하려는 경우 작업이 쉬워집니다. 어떤 경우에는 실제로 코드베이스에 대한 전체 액세스 권한을 부여하고 싶지 않습니다. 하나의 큰 모듈이 있으면 "외부인"이보고 편집 할 수있는 것을 제한하려는 경우 작업이 더 어려워집니다.
- 버그 소개 및 버그 수정, 프론트 엔드에 새로운 버그를 삽입했습니다. 그런 다음 누군가 백엔드에서 버그를 수정합니다. 하나의 리포지토리를 사용하면 새 버그 이전에 롤백하면 백엔드가 롤백되므로 수정하기가 어려울 수 있습니다. 프론트 엔드의 버그를 수정하는 동안 백엔드가 작동하도록하려면 다른 폴더에 백엔드를 복제해야합니다 ... 그런 다음 물건을 다시 만들려고합니다 ... 두 저장소를 갖는 것은 하나의 리포지토리의 HEAD를 이동했기 때문에 고통스럽지 않습니다. 다른 것을 바꾸지 마십시오. 그리고 다른 버전의 백엔드에 대한 테스트는 어려움이 없습니다.
누군가 나를 설득하기 위해 더 많은 주장을 주거나 적어도 두 개의 하위 모듈로 프로젝트를 나누는 것이 무의미한 (더 복잡한) 이유를 말해 줄 수 있습니까? 이 프로젝트는 새롭고 코드베이스는 며칠이어서 너무 빨리 고쳐지지 않습니다.