자식 브랜치의 이름을 지정하는 데 일반적으로 사용되는 몇 가지 예는 무엇입니까? [닫은]

몇 달 동안 내 그룹의 CVS 저장소와 상호 작용하는 로컬 자식 저장소를 사용하고 있습니다. 나는 거의 신경질적인 수의 가지를 만들었습니다. 그러나 이름이 문제가되고 있습니다. 간단한 레이블로 쉽게 이름이 지정된 작업이 있지만 각각 자체 분기 및 병합 상황을 포함하는 세 단계로 수행하면 매번 분기 이름을 반복 할 수 있지만 역사는 약간 혼란 스럽습니다. 각 단계마다 별도의 설명과 함께 이름을 더 구체적으로 지정하면 지점 이름이 길고 다루기 어려워지기 시작합니다.

나는 오래된 스레드를 통해 이름 / / 이름, 즉 주제 / 작업 또는 이와 유사한 이름으로 분기 이름을 지정할 수 있다는 것을 배웠습니다. 나는 그 일을 시작하고 그것이 더 나은 조직을 유지하는 데 도움이되는지 볼 수 있습니다.

자식 분기의 이름을 지정하는 모범 사례는 무엇입니까?

편집 : 실제로 아무도 명명 규칙을 제안하지 않았습니다. 작업이 끝나면 지점을 삭제합니다. 경영진이 끊임없이 우선 순위를 조정하기 때문에 몇 가지 상황이 발생합니다. :) 하나의 작업에 두 개 이상의 분기가 필요한 이유의 예로, 작업의 첫 번째 개별 마일스톤을 그룹의 CVS 리포지토리에 커밋해야한다고 가정합니다. 그 시점에서 CVS와의 불완전한 상호 작용으로 인해 커밋을 수행 한 다음 해당 분기를 종료합니다. (그 시점에서 동일한 브랜치를 계속 사용하려고하면 CVS와 상호 작용하는 이상한 점이 너무 많습니다.)

다음은 내가 사용하는 지점 명명 규칙과 그 이유입니다.

지점 명명 규칙

1. 지점 이름의 시작 부분에 그룹화 토큰 (단어)을 사용하십시오.
2. 짧은 리드 토큰을 정의하고 사용하여 워크 플로우에 의미있는 방식으로 분기를 차별화하십시오.
3. 슬래시를 사용하여 브랜치 이름의 일부를 분리하십시오.
4. 맨 앞에 숫자를 사용하지 마십시오.
5. 오래 지속되는 가지에 대해 긴 설명 이름을 사용하지 마십시오.

그룹 토큰

지점 이름 앞에 "그룹화"토큰을 사용하십시오.

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'.

Vincent Driessen 의 성공적인 Git 브랜칭 모델 에는 좋은 제안이 있습니다. 사진은 아래와 같습니다. 이 브랜칭 모델이 매력적이라면 git 흐름 확장을 고려하십시오 . 다른 사람들은 흐름에 대해 언급했습니다

Driessen의 모델은 다음과 같습니다.

• 릴리스에만 사용되는 마스터 분기입니다. 전형적인 이름 master.

• 해당 지점에서 "개발"지점 그것은 대부분의 주요 작업에 사용되는 것입니다. 일반적으로 이름이 develop입니다.

• 개발 지점에서 여러 기능 지점. 기능 이름을 기반으로 한 이름입니다. 이들은 마스터 또는 릴리스 브랜치가 아닌 개발로 다시 병합됩니다.

• 버그 수정 및 새로운 기능이없는 후보 릴리스를 보유하는 릴리스 브랜치. 전형적인 이름 rc1.1.

핫픽스는 마스터에서 제공되는 변경 사항을위한 단기 브랜치이며 개발 브랜치가 없어도 마스터로 변경됩니다.

개인적으로 선호하는 것은 토픽 브랜치가 끝나면 브랜치 이름을 삭제하는 것입니다.

브랜치의 의미를 설명하기 위해 브랜치 이름을 사용하는 대신, "브랜치 :"를 사용하여 해당 브랜치의 첫 번째 커밋에서 커밋 메시지의 제목 줄을 시작하고 제목이 다음과 같은 경우 메시지 본문에 추가 설명을 포함시킵니다. 공간이 충분하지 않습니다.

내가 사용하는 브랜치 이름은 순전히 토픽 브랜치를 다루는 핸들입니다. 토픽 브랜치에 대한 작업이 끝나면 브랜치 이름을 제거하고 때로는 나중에 참조하기 위해 커밋에 태그를 지정합니다.

따라서 출력의 git branch유용성도 향상됩니다. 모든 분기가 아니라 오래 지속되는 분기 및 활성 주제 분기 만 나열합니다.

나는 내가 본 다른 도구와 내가 사용하는 툴링을 기반으로 혼합하고 일치했습니다.
완성 된 지점 이름은 다음과 같습니다.

이름 / 기능 / 문제 추적기 번호 / 짧은 설명

이것은 다음과 같이 번역됩니다.

마이크 / 블로그 / RSSI-12 / 로고 수정

부품은 쉽게 정리할 수 있도록 SourceTree에서 폴더로 해석되므로 슬래시로 구분됩니다. Jira는 이슈 추적에 Jira를 사용하므로 숫자를 포함하면 시스템에서 쉽게 조회 할 수 있습니다. 이 번호를 포함하면 풀 요청을 제출하려고 할 때 Github에서 해당 문제를 찾을 때 검색 할 수 있습니다.

모든 작업에 세 개의 지점 / 병합이 필요한 이유는 무엇입니까? 그것에 대해 더 자세히 설명해 주시겠습니까?

버그 추적 시스템을 사용하는 경우 지점 이름의 일부로 버그 번호를 사용할 수 있습니다. 이렇게하면 분기 이름이 고유하게 유지되고 짧고 설명적인 단어 앞에 접두어를 붙여서 사람이 읽을 수있게합니다 "ResizeWindow-43523". 또한 관련된 버그를 찾을 수 있기 때문에 분기를 정리할 때 작업을보다 쉽게 ​​수행 할 수 있습니다. 이것이 내가 보통 지점 이름을 짓는 방법입니다.

이러한 브랜치는 결국 마스터로 다시 병합되므로 병합 후 안전하게 삭제해야합니다. 와 병합하지 않는 한 --squash지점의 전체 기록은 여전히 ​​필요합니다.

참고에 도시 된 바와 같이 e703d7 커밋 또는 b6c2a0d 커밋 힘내 2.0 (2014 월)을, 지금의, 다른 명명 규칙을 (당신이 지점에 적용 할 수있는) 찾을 수 있습니다.

"공간을 사용해야 할 때 대시를 사용하십시오"는 공백을 사용해서는 안된다는 이상한 방법입니다.
명령 행 설명에서 대시 다중 단어를 사용하는 것이 더 일반적이므로이 위치에는 공백을 사용하지 않아도됩니다.

브랜치 이름은 공백을 가질 수 없습니다 ( " 브랜치 이름에서 어떤 문자가 유효하지 않습니까? "및 git check-ref-format매뉴얼 페이지 참조 ).

따라서 여러 단어로 표현되는 모든 분기 이름에 대해 ' -'(대시)를 구분 기호로 사용하는 것이 좋습니다.

farktronix의 제안에 따라, 우리는 수은과 유사하게 Jira 티켓 번호를 사용하고 있으며 git 브랜치에 계속 사용할 계획입니다. 그러나 티켓 번호 자체는 충분히 독창적이라고 생각합니다. farktronix가 지적한대로 브랜치 이름에 설명적인 단어를 사용하는 것이 도움이 될 수 있지만 브랜치 사이를 자주 전환하는 경우 타이핑을 원치 않을 수 있습니다. 그런 다음 지점 이름을 알아야하는 경우 Jira에서 티켓의 관련 키워드를 모르는 경우 해당 키워드를 찾으십시오. 또한 각 주석에 티켓 번호를 포함시켜야합니다.

지점이 버전을 나타내는 경우 일반적인 규칙은 지점 이름으로 xxx (예 : "1.0.0") 형식을 사용하고 태그 이름으로 vx.xx (예 : "v1.0.0")를 사용하여 충돌을 피하는 것 같습니다. . 참조 : 표준 이름 지정 컨벤션-git-tags