git 브랜치를 명명하는 데 일반적으로 사용되는 관행의 몇 가지 예

질문 : git 브랜치를 명명하는 데 일반적으로 사용되는 관행의 몇 가지 예는 무엇입니까?

---

나는 몇 달 동안 내 그룹의 CVS 저장소와 상호 작용하는 로컬 git 저장소를 사용하고 있습니다. 나는 거의 신경증적인 수의 가지를 만들었는데, 대부분은 고맙게도 내 몸통에 다시 합쳐졌습니다. 그러나 이름 지정이 문제가되기 시작했습니다. 간단한 레이블로 쉽게 명명 할 수있는 작업이 있지만 각각 고유 한 분기와 병합 상황을 포함하는 3 단계로 수행하면 매번 분기 이름을 반복 할 수 있지만 이로 인해 기록이 약간 혼란스러워집니다. 각 단계에 대한 별도의 설명을 사용하여 이름을 더 구체적으로 지정하면 지점 이름이 길고 다루기 어려워집니다.

여기에서 오래된 스레드를 살펴보면서 이름에 /를 사용하여 분기 이름을 지정할 수 있다는 것을 배웠습니다 (예 : 주제 / 작업 또는 이와 유사한 것). 나는 그것을 시작하고 그것이 일을 더 잘 정리하는 데 도움이되는지 볼 수 있습니다.

git 브랜치를 명명하는 모범 사례는 무엇입니까?

편집 : 아무도 실제로 명명 규칙을 제안하지 않았습니다. 작업이 끝나면 브랜치를 삭제합니다. 관리가 지속적으로 우선 순위를 조정하기 때문에 주변에 여러 가지가 있습니다. :) 작업에 두 개 이상의 분기가 필요한 이유에 대한 예로 작업의 첫 번째 개별 마일스톤을 그룹의 CVS 저장소에 커밋해야한다고 가정합니다. 그 시점에서 CVS와의 불완전한 상호 작용으로 인해 해당 커밋을 수행 한 다음 해당 분기를 종료합니다. (그 시점에서 동일한 분기를 계속 사용하려고하면 CVS와 상호 작용하는 이상 함을 너무 많이 보았습니다.)

답변

---

내가 사용하는 몇 가지 분기 명명 규칙과 그 이유는 다음과 같습니다.

분기 명명 규칙

그룹 토큰

브랜치 이름 앞에 "그룹화"토큰을 사용하십시오.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

그룹 이름은 워크 플로에 맞게 원하는대로 지정할 수 있습니다. 나는 짧은 명사를 사용하는 것을 좋아합니다. 더 명확하게 읽으려면 계속 읽으십시오.

짧고 잘 정의 된 토큰

짧은 토큰을 선택하여 모든 지점 이름에 너무 많은 노이즈를 추가하지 않도록하십시오. 나는 이것을 사용합니다 :

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

이러한 각 토큰을 사용하여 각 분기가 속한 워크 플로의 부분을 알 수 있습니다.

변화의 다른주기에 대해 여러 분기가있는 것 같습니다. 나는 당신의주기가 무엇인지 모르지만 그것이 '신규', '테스트'및 '확인'이라고 가정합시다. 이러한 태그의 축약 된 버전을 사용하여 브랜치의 이름을 항상 같은 방식으로 지정하여 그룹화하고 현재 어느 단계에 있는지 상기 할 수 있습니다.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

각 단계에 도달 한 브랜치를 빠르게 알 수 있으며 Git의 패턴 일치 옵션을 사용하여 쉽게 그룹화 할 수 있습니다.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

슬래시를 사용하여 부분 분리

브랜치 이름에 좋아하는 구분 기호를 대부분 사용할 수 있지만 슬래시가 가장 유연하다는 것을 알았습니다. 대시 또는 점을 사용하는 것이 좋습니다. 그러나 슬래시를 사용하면 원격으로 푸시하거나 가져올 때 분기 이름을 변경할 수 있습니다.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

나에게 슬래시는 내 쉘의 탭 확장 (명령 완성)에도 더 잘 작동합니다. 내가 구성한 방식으로 부품의 첫 문자를 입력하고 TAB 키를 눌러 다른 하위 부품이있는 분기를 검색 할 수 있습니다. Zsh는 내가 입력 한 토큰의 일부와 일치하는 분기 목록을 제공합니다. 이는 이전 토큰과 포함 된 토큰에 대해 작동합니다.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell은 명령 완성에 대해 매우 구성 할 수 있으며 대시, 밑줄 또는 점을 동일한 방식으로 처리하도록 구성 할 수도 있습니다.하지만 그렇게하지 않기로 선택했습니다.)

또한 다음과 같이 많은 git 명령에서 분기를 검색 할 수 있습니다.

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*"

주의 사항 : Slipp이 주석에서 지적했듯이 슬래시는 문제를 일으킬 수 있습니다. 분기는 경로로 구현되기 때문에 "foo"라는 분기와 "foo / bar"라는 다른 분기를 가질 수 없습니다. 신규 사용자에게는 혼동을 줄 수 있습니다.

베어 숫자를 사용하지 마십시오

브랜치 이름 지정 체계의 일부로 베어 숫자 (또는 16 진수)를 사용하지 마십시오. 참조 이름의 탭 확장 내에서 git은 숫자가 분기 이름 대신 sha-1의 일부라고 결정할 수 있습니다. 예를 들어, 내 이슈 트래커는 10 진수로 버그를 명명합니다. 혼동을 피하기 위해 관련 브랜치의 이름을 nnnnn이 아닌 CRnnnnn으로 지정합니다.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

15032 만 확장하려고하면 git은 내가 SHA-1 또는 브랜치 이름을 검색할지 여부를 확신 할 수 없으며 내 선택이 다소 제한됩니다.

긴 설명 이름을 피하십시오

긴 브랜치 이름은 브랜치 목록을 볼 때 매우 유용 할 수 있습니다. 그러나 분기 이름이 대부분의 단일 행을 차지하고 로그의 보이는 부분을 축약 할 수 있기 때문에 장식 된 단선 통나무를 볼 때 방해가 될 수 있습니다.

반면에 긴 브랜치 이름은 습관적으로 수동으로 다시 작성하지 않는 경우 "커밋 병합"에 더 유용 할 수 있습니다. 기본 병합 커밋 메시지는 Merge branch 'branch-name' 입니다. 당신은 더 도움이 병합 메시지로 표시하도록 찾을 수 있습니다 Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' 대신 단지 Merge branch 'fix/CR15032' .

출처 : https://stackoverflow.com/questions/273695/what-are-some-examples-of-commonly-used-practices-for-naming-git-branches