개발자

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

2023년 04월 25일조회 186

새로운 회사로 이직 한지 얼마 안된 3년차 주니어 웹 개발자입니다. 현재 회사가 IT 업체가 아니라 모든 개발과 운영을 개발 업체에 맡긴 상태입니다. 회사에서는 인하우스 개발자의 필요성을 느껴 구인을 했고, 제가 들어왔는데 모든 프로젝트 소스를 인수인계 받음에 앞서 형상 관리에 대한 의견 충돌이 생겨 질문 드립니다. 현재는 운영 중인 여러개의 웹 프로젝트를 같은 레포지토리에 관리 하고 있습니다. 보통 기능 개발 같은게 들어오면 웹 별 비슷한 기능을 어차피 한꺼번에 반영해야해서 한번에 수정 후 1 commit을 하고 있다고 합니다. 충돌날 일도 거의 없다고 브랜치는.. 나누지 않는다고 합니다. 이것부터 이해가 안되긴 합니다. 저는 이전 회사에서 프로젝트 별 레포지토리를 생성하여 관리 했었습니다. 물론 기능 추가를 하더라도 유의미한 커밋은 여러번 했었고요. 그냥 그런 방식이 당연하다고 생각했습니다. 저는 이전 경험처럼 형상 관리를 나눠서 하고 싶은데 개발업체 개발자가 납득할만한 설명이 바로 떠오르지 않았습니다. 그래서 일단 보류해둔 상태입니다. 뭔가.. 이상한 것 같은데 어떤 근거를 들어가며 설득해야할지 모르겠습니다. 이미 그런 방식으로 계속 개발/운영 해오던 거라 그 쪽도 현재 관리 방법을 고수하고 싶은 것 같습니다. 위 내용에 대해 조언을 주신다면 감사하겠습니다. 혹시나 제 질문이 이해가 안 되신다고 해도 댓글 부탁드리겠습니다. ㅠㅠ 현재 회사에 입사한지도 얼마 안됐고 개발자가 저 한 명이라 도움 구할 사람이 없네요..

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.
profile picture
익명님의 질문

답변 2

강서지님의 프로필 사진

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

커리어리 AI 봇님의 프로필 사진

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

커리어리 AI 봇의 답변을 평가해 주세요!

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

목록으로
키워드로 질문 모아보기

실무, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!