git 서브 모듈로 공용 라이브러리를 공유하는 git 프로젝트가 있습니다. 프로젝트를 변경할 때 항상 작업을 수행 할 자식 브랜치를 만듭니다. 테스트를 마친 후 또 다른 눈을 받으면 브랜치를 다시 병합하여 항상 배포 준비가 된 마스터로 만듭니다.Git Submodules로 작업하는 적절한 방법은 무엇입니까
때로는 하위 모듈 라이브러리도 변경해야합니다. 가장 좋은 방법은 먼저 주 프로젝트를 분기 한 다음 하위 모듈로 이동하여 분기하는 것입니까? 다른 프로젝트에서 수정 된 하위 모듈을 테스트해야합니다. 이 작업을 수행하는 다른 방법이 있습니까?
git submodule 자체 프로젝트입니다. 따라서 서브 모듈을 분기하는 정책은 모든 분기 결정과 동일한 고려 사항에 의해 정의됩니다. 하위 모듈이 동시에 개발 될 예정입니까? 마스터의 역사를 오염시키지 않으면 서 변경 사항을 되감 으시겠습니까? 예, 테스트도 고려 사항 일 수 있지만 다른 프로젝트에서 제대로 재사용 할 수있는 서브 모듈의 목표 여야합니다.
나는 멀티 서브 메인 프로젝트에서 작업하면서 공유 서브 모듈을 사용하는 두 개의 프로젝트를 가지고있다. 나는 서브 모듈을 분기 할 필요가 거의 없다. 그러나 때로는 물론 거기에 있습니다.
하위 모듈을 분기하거나 분기하지 않으려면 그 질문이 필요하지만 완전히 전적으로 사용자에게 달려 있습니다. 하위 모듈이 라이브러리이고 다른 프로젝트에서이 모듈을 사용중인 경우 은과 호환되어야합니다. 당신은 그 안에있는 것들을 고칠 수도 있지만 그 API를 만지지 마라. 그러나 lib 픽스는 실제로 lib의 마스터 브랜치에 속합니다. 따라서 주 프로젝트를 분기 할 때 자동으로 하위 모듈을 분기 할 이유는 없습니다.
기술적으로 중요한 점은 하위 모듈과 기본 프로젝트를 수정하고 커밋하는 경우 하위 모듈을 먼저 누른 다음 기본 프로젝트를 밀어 넣는 것입니다. 재귀 적 푸시와 같은 것은 없습니다.