Git 레포지토리 관리는 보통 어떻게 하시나요?

레포지토리 관리는 회사별로 혹은 프로덕트별로 전략을 다르게 가져갈 수 있는 부분이라 반드시 어느 쪽이 더 낫다고 말하기는 어려울 것 같습니다. 다만 장기적으로 볼 때 프로젝트 규모는 일반적으로 계속 커질 것이고, 그럴 수록 모노레포 전략의 단점이 두드러질 수 있겠죠. 커밋은 저도 그렇고 주변 사람들도 보면 어느 정도 나눠서 올리는 게 일반적인 것 같습니다. 적당히 semantic한 기준으로 나눌 때도 있고요. 기능 하나를 개발하더라도 기본적인 컴포넌트를 만들고 로직을 구현하고, 디자인적인 부분을 리터칭하여 수정하는 등 여러 가지 단계가 있다보니, 커밋이 세분화되어 있는 것이 문제를 찾아 해결하기 훨씬 용이하다고 생각되더라고요. 모쪼록 협의점을 잘 찾으실 수 있으면 좋겠습니다.

먼저, 각 회사와 팀마다 소스 코드 관리 방식이 다를 수 있으므로, 어떤 방식이 절대적으로 옳은 것은 아닙니다. 하지만 일반적인 현업에서의 Git 레포지토리 관리 방식에 대해 설명해드리겠습니다. 1. 프로젝트 별 레포지토리 생성: 대부분의 경우, 각 웹 프로젝트별로 별도의 레포지토리를 생성하여 관리하는 것이 일반적입니다. 이렇게 하는 이유는 프로젝트 간에 독립성을 유지하고, 코드 베이스를 명확하게 분리함으로써 개발 및 유지보수를 용이하게 하기 위함입니다. 2. 브랜치 관리: 브랜치를 사용하여 기능별, 버그 수정별 등 작업을 분리하여 관리하며, 코드 리뷰 및 병합 과정을 거쳐 마스터 브랜치에 합치는 것이 일반적입니다. 이를 통해 여러 개발자들이 동시에 작업하더라도 충돌을 최소화하고, 코드 품질을 유지할 수 있습니다. 3. 의미 있는 커밋: 커밋은 가능한 작은 단위로 나누어 작업한 내용을 기록합니다. 이를 통해 추후 문제 발생 시 원인을 쉽게 찾을 수 있으며, 이력을 통해 프로젝트의 변화를 명확하게 이해할 수 있습니다. 개발 업체와의 협력에서 현재 상황을 개선하려면 다음과 같은 방법을 제안해볼 수 있습니다: 1. 프로젝트 별 레포지토리 분리의 필요성을 설명하고, 각 프로젝트의 독립성과 코드 베이스의 명확한 분리를 통해 개발 및 유지보수가 용이해질 것임을 강조해보세요. 2. 브랜치를 사용한 작업 분리와 코드 리뷰 프로세스를 제안하고, 이를 통해 개발자들이 서로의 코드를 검토하며 코드 품질을 높일 수 있음을 설명하세요. 3. 작은 단위의 의미 있는 커밋을 통해 프로젝트 이력을 명확하게 관리할 것을 제안하고, 이로 인해 문제 발생 시 원인을 쉽게 찾을 수 있음을 설명하세요. 최종적으로, 현재의 방식보다 더 효율적이고 체계적인 소스 코드 관리 방식을 도입함으로써 전체적인 프로젝트 관리 및 개발 속도를 높일 수 있음을 설득력 있게 전달해보세요. 그러나 개발 업체와의 협업 상황을 고려하여, 서로 타협점을 찾아내는 것도 중요합니다. 참고로, 관리 방식 변경에 따른 시간과 노력이 필요하겠지만, 장기적으로 볼 때 코드 품질과 개발 효율성이 향상될 것이므로 변화에 대한 긍정적인 결과를 강조해보는 것도 좋습니다. 협업을 통해 개발자 간의 소통 및 이해가 높아지게 되면, 개발 프로세스와 결과물에 대한 만족도도 함께 높아질 것입니다. 이러한 점들을 강조하여 개발 업체와의 협력 관계를 개선해 나가길 바랍니다.