저는 지금 몇 달 동안 그룹의 CVS 저장소와 상호 작용하는 로컬 git 저장소를 사용해 왔습니다. 나는 거의 신경질적인 수의 가지를 만들었고, 대부분은 고맙게도 내 트렁크에 다시 병합되었습니다. 그러나 네이밍이 문제가 되기 시작했습니다. 간단한 레이블로 쉽게 이름을 지정할 수 있는 작업이 있지만 각각 고유한 분기 및 병합 상황을 포함하는 3단계로 수행하는 경우 매번 분기 이름을 반복할 수 있지만 이는 히스토리를 약간 혼란스럽게 만듭니다. 각 단계에 대한 별도의 설명과 함께 이름을 더 구체적으로 지정하면 분기 이름이 길고 다루기 어려워지기 시작합니다.
여기에서 이전 스레드를 살펴보고 이름에 /가 포함된 분기 이름 지정을 시작할 수 있다는 것을 배웠습니다. 즉, topic/task 또는 이와 유사한 것입니다. 나는 그것을 시작하고 그것이 일을 더 잘 정리하는 데 도움이되는지 볼 수 있습니다.
git 브랜치 이름 지정에 대한 모범 사례는 무엇입니까?
편집: 아무도 실제로 명명 규칙을 제안하지 않았습니다. 작업이 끝나면 분기를 삭제합니다. 경영진이 내 우선 순위를 지속적으로 조정하기 때문에 주변에 몇 개가 있습니다. :) 작업에 하나 이상의 분기가 필요한 이유에 대한 예로 작업의 첫 번째 개별 마일스톤을 그룹의 CVS 저장소에 커밋해야 한다고 가정합니다. 그 시점에서 CVS와의 불완전한 상호 작용으로 인해 해당 커밋을 수행한 다음 해당 분기를 종료합니다. (그 시점에서 동일한 분기를 계속 사용하려고 하면 CVS와 상호 작용하는 이상함을 너무 많이 보았습니다.)
그룹 이름은 워크플로에 맞게 원하는 대로 지정할 수 있습니다. 나는 짧은 명사를 사용하는 것을 좋아합니다. 더 명확하게 읽으려면 계속 읽으십시오.
짧고 잘 정의된 토큰
모든 지점 이름에 너무 많은 노이즈를 추가하지 않도록 짧은 토큰을 선택하십시오. 나는 이것을 사용한다:
wip Works in progress; stuff I know won't be finished soon feat Feature I'm adding or expanding bug Bug fix or experiment junk Throwaway branch created to experiment
이러한 각 토큰을 사용하여 각 분기가 속한 워크플로 부분을 알 수 있습니다.
변경 주기에 따라 여러 분기가 있는 것처럼 들립니다. 나는 당신의 주기가 무엇인지 모르지만 '신규', '테스트' 및 '검증'된 주기라고 가정해 보겠습니다. 항상 같은 철자가 같은 이러한 태그의 축약된 버전으로 분기의 이름을 지정하여 그룹화하고 현재 어느 단계에 있는지 상기시킬 수 있습니다.
나에게 슬래시는 내 셸의 탭 확장(명령 완성)에도 더 잘 작동합니다. 내가 구성한 방식으로 파트의 첫 번째 문자를 입력하고 TAB 키를 눌러 다른 하위 파트가 있는 분기를 검색할 수 있습니다. 그런 다음 Zsh는 내가 입력한 토큰의 일부와 일치하는 분기 목록을 제공합니다. 이는 포함된 토큰뿐만 아니라 이전 토큰에도 적용됩니다.
주의 사항: Slipp이 주석에서 지적했듯이 슬래시는 문제를 일으킬 수 있습니다. 분기는 경로로 구현되므로 "foo"라는 분기와 "foo/bar"라는 다른 분기를 가질 수 없습니다. 이것은 새로운 사용자에게 혼란을 줄 수 있습니다.
맨 숫자를 사용하지 마십시오.
분기 명명 체계의 일부로 베어 숫자(또는 16진수)를 사용하지 마십시오. 참조 이름의 탭 확장 내부에서 git은 숫자가 분기 이름 대신 sha-1의 일부라고 결정할 수 있습니다. 예를 들어, 내 이슈 트래커는 십진수로 버그의 이름을 지정합니다. 혼동을 피하기 위해 관련 분기의 이름을 nnnnn이 아니라 CRnnnnn으로 지정합니다.
15032만 확장하려고 하면 git은 내가 SHA-1 또는 분기 이름을 검색할지 여부를 확신할 수 없으며 선택 항목이 다소 제한됩니다.
설명이 긴 이름은 피하세요.
긴 브랜치 이름은 브랜치 목록을 볼 때 매우 유용할 수 있습니다. 그러나 분기 이름이 대부분의 단일 행을 먹고 로그의 보이는 부분을 축약할 수 있으므로 장식된 한 줄 로그를 볼 때 방해가 될 수 있습니다.
반면에 손으로 습관적으로 다시 작성하지 않으면 긴 분기 이름이 "커밋 병합"에 더 도움이 될 수 있습니다. 기본 병합 커밋 메시지는 Merge branch 'branch-name' 입니다. 당신은 더 도움이 병합 메시지로 표시하도록 찾을 수 있습니다 Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' 대신 단지 Merge branch 'fix/CR15032' .
해당 분기에서 "개발" 분기입니다. 대부분의 메인 라인 작업에 사용되는 것입니다. 일반적으로 이름이 develop .
개발 분기의 여러 기능 분기. 기능의 이름을 기반으로 하는 이름입니다. 이들은 마스터 또는 릴리스 분기가 아닌 개발로 다시 병합됩니다.
버그 수정만 있고 새로운 기능은 없는 후보 릴리스를 보유하는 릴리스 분기입니다. 일반적인 이름 rc1.1 .
핫픽스는 마스터에서 오는 변경 사항에 대한 단기 분기이며 개발 분기가 관여하지 않고 마스터로 이동합니다.
Brian Carlton
나는 내가 본 다른 구성표와 내가 사용하는 도구를 기반으로 혼합 및 일치했습니다. 따라서 완성된 지점 이름은 다음과 같습니다.
이름/기능/문제 추적기 번호/짧은 설명
다음과 같이 번역됩니다.
mike/blogs/RSSI-12/logo-fix
쉽게 구성할 수 있도록 SourceTree에서 폴더로 해석되기 때문에 해당 부분은 슬래시로 구분됩니다. 문제 추적에 Jira를 사용하므로 번호를 포함하면 시스템에서 더 쉽게 조회할 수 있습니다. 해당 번호를 포함하면 pull 요청을 제출하려고 할 때 Github 내에서 해당 문제를 찾으려고 할 때 검색할 수 있습니다.
MikeG
내 개인적인 취향은 토픽 브랜치를 마친 후 브랜치 이름을 삭제하는 것입니다.
브랜치의 의미를 설명하기 위해 브랜치 이름을 사용하는 대신, 해당 브랜치의 첫 번째 커밋에서 커밋 메시지의 제목 줄을 "Branch:"로 시작하고 제목이 다음과 같은 경우 메시지 본문에 추가 설명을 포함합니다. 나에게 충분한 공간을주지 않습니다.
내가 사용하는 브랜치 이름은 작업하는 동안 토픽 브랜치를 참조하기 위한 핸들입니다. 토픽 브랜치에 대한 작업이 끝나면 브랜치 이름을 지우고 나중에 참조할 수 있도록 커밋에 태그를 지정하기도 합니다.
git branch 의 출력을 더욱 유용하게 만듭니다. 모든 브랜치가 아니라 수명이 긴 브랜치와 활성 토픽 브랜치만 나열합니다.
Aristotle Pagaltzis
모든 작업에 대해 3개의 분기/병합이 필요한 이유는 무엇입니까? 그것에 대해 더 설명할 수 있습니까?
버그 추적 시스템을 사용하는 경우 버그 번호를 분기 이름의 일부로 사용할 수 있습니다. "ResizeWindow-43523" 과 같이 사람이 읽을 수 있도록 짧고 설명적인 단어를 접두사로 사용할 수 있습니다. 또한 관련 버그를 조회할 수 있으므로 분기를 정리할 때 작업을 더 쉽게 수행할 수 있습니다. 이것은 일반적으로 내 지점의 이름을 지정하는 방법입니다.
이러한 분기는 결국 마스터로 다시 병합되므로 병합 후 안전하게 삭제해야 합니다. --squash 와 병합하지 않는 한 분기의 전체 기록은 필요할 때 계속 존재합니다.
따라서 다중 단어 표현식으로 표시되는 모든 분기 이름에 대해 ' - '(대시)를 구분 기호로 사용하는 것이 좋습니다.
VonC
farktronix의 제안에 따라 mercurial에서 유사한 Jira 티켓 번호를 사용하고 있으며 git 분기에 계속 사용할 계획입니다. 하지만 티켓 번호 자체가 아마 충분히 독특하지 않을까 생각합니다. farktronix가 언급한 것처럼 분기 이름에 설명적인 단어가 있으면 도움이 될 수 있지만 분기 간에 자주 전환하는 경우 입력을 덜 원할 것입니다. 그런 다음 분기 이름을 알아야 하는 경우 모르는 경우 Jira에서 티켓의 관련 키워드를 찾습니다. 또한 각 댓글에 티켓 번호를 포함해야 합니다.
