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/*"
주의: Slip이 댓글에서 지적했듯이 슬래시는 문제를 일으킬 수 있습니다.브랜치는 경로로 구현되므로 "foo"라는 브랜치와 "foo/bar"라는 다른 브랜치를 가질 수 없습니다.이것은 신규 사용자에게 혼란을 줄 수 있습니다.
맨 숫자 사용 안 함
브랜치 명명 방식의 일부로 베어 숫자(또는 16진수)를 사용하지 마십시오.참조명의 탭 내에서는, git는 번호가 지점명이 아닌 sha-1의 일부라고 판단합니다.예를 들어, 제 이슈 트래커는 버그를 10진수로 명명합니다.혼란을 피하기 위해 관련 브랜치 이름을 nnnnnn이 아닌 CRnnnn으로 지었습니다.
$ git checkout CR15032<TAB>
Menu: fix/CR15032 test/CR15032
15032만 확장하려고 하면 GIT가 SHA-1을 검색해야 할지 지점 이름을 검색해야 할지 망설여져 선택의 폭이 다소 좁아집니다.
설명이 긴 이름은 사용하지 마십시오.
지점 이름을 길게 지정하면 지점 목록을 볼 때 매우 유용합니다.그러나 분기 이름이 한 줄의 대부분을 차지하고 로그의 보이는 부분을 생략할 수 있기 때문에 장식된 한 줄의 로그를 볼 때 방해가 될 수 있습니다.
한편, 브런치명을 수동으로 정기적으로 고쳐 쓰지 않는 경우는, 「커밋」에 있어서, 긴 브런치명이 도움이 됩니다.는 "Marge" 입니다.Merge branch 'branch-name'. Marge 가 로 더이 될 수 Mage Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Maje Majuffecteddge Ma.Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'한 것이 Merge branch 'fix/CR15032'.
Vincent Driessen의 성공적인 Git 분기 모델은 좋은 제안을 합니다.아래 사진이 있습니다.이 분기 모델이 마음에 든다면 git로의 흐름 확장을 고려해 보십시오.다른 사용자가 흐름에 대해 코멘트했습니다.
Driessen의 모델에는 다음이 포함됩니다.
표준명 " " "'
master.그 지점의 "개발" 지점입니다.그것은 대부분의 주요 업무에서 사용되는 것입니다. ''
develop.여러 기능 브랜치가 개발 브랜치에서 분리되어 있습니다.기능의 이름에 근거한 이름.이것들은 마스터 브랜치나 릴리스 브랜치가 아닌 개발 브랜치로 다시 통합됩니다.
후보 릴리스를 유지하는 릴리스 브랜치를 릴리스합니다.버그 수정만 있고 신기능은 없습니다. '''
rc1.1.
핫픽스는 마스터에서 발생하는 변경에 대한 단기간의 브랜치이며 개발 브랜치가 관여하지 않고 마스터로 이행됩니다.
지금까지 본 다양한 스킴과 사용하고 있는 툴링을 조합해 보았습니다.
완성된 브랜치명은 다음과 같습니다.
name/module/issue-module-number/short-description
즉, 다음과 같습니다.
마이크/블로그/RSSI-12/logo-fix
구성하기 쉽도록 SourceTree에서 폴더로 해석되기 때문에 부품은 슬래시로 구분됩니다.문제 추적에는 Jira를 사용하기 때문에 번호를 포함하여 시스템에서 조회하기 쉽습니다.이 번호를 포함하면 풀 요청을 제출할 때 Github 내에서 해당 문제를 검색하려고 할 때도 검색이 가능합니다.
개인적으로는 토픽 브랜치를 종료한 후에 브랜치명을 삭제하는 것을 선호합니다.
브랜치 이름을 사용하여 브랜치의 의미를 설명하는 대신 해당 브랜치 상의 첫 번째 커밋 메시지 제목 행을 "Branch:"로 시작하고 제목에 충분한 공간이 없는 경우 메시지 본문에 추가 설명을 포함합니다.
제가 사용하고 있는 지점명은, 작업중에 토픽 브랜치를 참조하기 위한 핸들입니다.토픽 브랜치에 대한 작업이 완료되면 브랜치 이름을 삭제하고 나중에 참조할 수 있도록 커밋에 태그를 붙입니다.
하면 그, 의, 의, of, 의, 니의 출력이 됩니다.git branch또한 긴 수명 브랜치 및 활성 토픽 브랜치만 나열하고 모든 브랜치는 나열하지 않습니다.
각 태스크에 3개의 브랜치/머지가 필요한 이유는 무엇입니까?그것에 대해 좀 더 설명해 주시겠어요?
버그 추적 시스템을 사용하는 경우 버그 번호를 지점 이름의 일부로 사용할 수 있습니다.고유하게 되고, 앞에 알기 쉬운 개를 붙여서 수 할 수 ."ResizeWindow-43523" 브런치를 갈 버그를 할 수 에, 브런치를 하기 위해서도 도움이 저는 보통 이렇게 지명을 짓습니다.
이들 브랜치는 최종적으로 마스터로 Marge되므로 Marge 후 안전하게 삭제할 수 있습니다.--squash브랜치의 모든 이력은, 필요에 따라서 계속 존재합니다.
참고로 현재 Git 2.0의 일부인 commit e703d7 또는 commit b6c2a0d(2014년 3월)에서 설명한 바와 같이 (브런치에 적용할 수 있는) 다른 명명 규칙을 찾을 수 있습니다.
"스페이스를 사용해야 할 때 대시 사용"은 공간을 사용해서는 안 된다는 이상한 표현입니다.
명령줄 설명에서는 파선된 다중 단어를 사용하는 것이 일반적이기 때문에 이러한 장소에서는 공백조차 사용하지 않습니다.
지점 이름에는 공백을 사용할 수 없습니다("지점 이름 내에서 잘못된 문자?" 및 man 페이지 참조).
따라서 여러 단어 표현으로 표현되는 모든 지점 이름에 대해 '를 사용합니다.-구분자로서 (구분자)를 사용하는 것이 좋습니다.
farktronix의 제안에 따라, 우리는 Jira 티켓 번호를 mercurial과 유사한 번호로 사용하고 있으며, 앞으로도 git 브랜치에 사용할 예정입니다.하지만 티켓 번호 자체는 충분히 독특할 것 같아요.farktronix가 지적한 것처럼 브랜치 이름에 알기 쉬운 단어가 있으면 도움이 될 수 있지만 브랜치 간에 자주 전환되는 경우에는 입력하는 것을 줄일 수 있습니다.그리고 지점명을 알고 싶다면 티켓에 기재되어 있는 관련 키워드를 지라에서 찾아보세요.또한 각 코멘트에 티켓 번호를 포함해야 합니다.
브런치가 버전을 나타내는 경우는, 공통의 표기법으로 브랜치명에 x.x.x(예: "1.0.0") 형식을 사용하고, 태그명에 vx.x(예: "v1.0.0") 형식을 사용해 경합을 회피하는 것이 있습니다.참조 항목: is-there-an-standard-naming-convention-for-git-tags
언급URL : https://stackoverflow.com/questions/273695/what-are-some-examples-of-commonly-used-practices-for-naming-git-branches
'programing' 카테고리의 다른 글
| Bash를 사용하여 마지막 명령어의 출력을 자동으로 변수에 캡처하시겠습니까? (0) | 2023.04.17 |
|---|---|
| JavaScript 문자열을 모두 소문자로 변환 (0) | 2023.04.17 |
| shell에서 source 명령을 찾을 수 없습니다. (0) | 2023.04.17 |
| R 스크립트에서 Excel 파일 직접 읽기 (0) | 2023.04.12 |
| @synthe size는 정확히 어떤 역할을 합니까? (0) | 2023.04.12 |