깃 브랜치 네이밍 규칙 트러블슈팅: "슬래시 문제와 해결 방안"

 

 

깃 브랜치 네이밍 규칙 트러블슈팅: "슬래시 문제와 해결 방안"

 

 

최근에 깃 브랜치 네이밍 전략을 운영하면서 한 가지 문제가 발생했다.

 

바로 슬래시(/)를 사용한 브랜치 네이밍 규칙이 의도치 않게 오류를 발생시키는 상황이었다.

이 문제를 해결하기 위한 고민과 해결 방안을 공유해보고자 한다.

 

 

문제 발생

우리 팀에서는 깃 브랜치 네이밍 규칙으로, 각 개발자가 작업한 기능을 구분하기 위해 브랜치 이름에 슬래시(/)를 사용하여 계층 구조를 만들고 있다.

 

예를 들어 feature/member/social-login처럼, 각 기능의 이름을 feature/, member/, social-login으로 나누어 표기하고 있었다. 그런데, 이처럼 슬래시를 사용한 이름을 가진 브랜치가 이미 존재하면, 하위 브랜치를 만들 수 없다는 문제가 발생했다.

 

$ git branch feature/member/social-login/xxxxxxx
fatal: cannot lock ref 'refs/heads/feature/member/social-login/xxxx': 'refs/heads/feature/member/social-login' exists; cannot create 'refs/heads/feature/member/social-login/minsmin97'

 

 

이 오류는 Git이 슬래시(/)를 디렉토리 구분자로 인식해서 발생한 것이다. 즉, feature/member/social-login이라는 브랜치가 이미 존재하면, Git은 이를 "디렉토리"처럼 처리하고, feature/member/social-login/xxxxxxx 같은 하위 브랜치를 만들 수 없다고 판단한 것이다.

 

 

 

고민과 해결 방안

이 문제를 해결하기 위해 여러 가지 방법을 고려해봤다. 그 중에서 두 가지 해결 방안을 생각해냈다.

 

 

1. social-login/basic으로 브랜치 네이밍하기

첫 번째 방법은 기존 브랜치 이름에서 social-login 브랜치명을 그대로 사용하되, 하위 브랜치를 basic 같은 다른 이름으로 만들어주는 것이다. 예를 들어, social-login/basic이라는 이름으로 브랜치를 만들면, 그 후에 social-login/xxxxxx과 같은 하위 브랜치를 만들 때 오류가 발생하지 않는다.

 

이 방법은 기존의 브랜치 전략을 수정할 필요가 없어서 가장 간편하고 빠르게 적용할 수 있었다. 기존의 네이밍 규칙을 유지하면서도, 오류를 피할 수 있는 좋은 방법이었다.

 

 

 

2. 하위 브랜치에 대시(-) 사용하기

두 번째 방법은 하위 브랜치 이름에 대시(-)를 사용하는 것이다. 예를 들어, social-login/xxxxxx대신 social-login-xxxxxx처럼 하위 브랜치를 만들어주면, 슬래시(/)를 사용하지 않으므로 Git이 디렉토리 구조로 인식하지 않게 된다.

 

이 방법은 하위 브랜치 네이밍을 조금 변경하는 것만으로 해결할 수 있지만, 기존 브랜치 전략에서 슬래시(/)를 사용하는 규칙을 바꿔야 하므로 조금 더 신중한 결정이 필요했다.

 

 

결론

결국 우리는 첫 번째 방법인 social-login/basic 형태로 브랜치 네이밍을 적용하기로 결정했다.

 

이는 기존의 네이밍 전략을 크게 수정하지 않고도 문제를 해결할 수 있어, 팀 내에서 빠르게 적용할 수 있었다.

 

물론 두 번째 방법인 대시(-) 사용도 고려했지만, 팀의 기존 네이밍 규칙에 큰 영향을 주지 않으면서 문제를 해결할 수 있다는 점에서 첫 번째 방법을 선택했다.

 

이와 같은 문제를 경험하면서, 깃 브랜치 네이밍 규칙이 예상치 못한 오류를 일으킬 수 있다는 것을 알게 되었고, 이를 해결하는 두 가지 방법을 적용할 수 있었다. 브랜치 네이밍 규칙은 프로젝트의 진행에 중요한 역할을 하므로, 프로젝트 초기에 이러한 작은 문제들에 대해 미리 고민하고 해결책을 마련해보는것도 좋은것 같다.