git 브랜치 이름을 지정하는 데 일반적으로 사용되는 관행의 예는 무엇입니까?

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

---

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

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

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

편집 : 아무도 실제로 명명 규칙을 제안하지 않았습니다. 작업이 끝나면 분기를 삭제합니다. 관리가 지속적으로 우선 순위를 조정하기 때문에 여러 가지가 있습니다. :) 작업에 두 개 이상의 분기가 필요한 이유에 대한 예로 작업의 첫 번째 개별 마일스톤을 그룹의 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"라는 다른 분기를 가질 수 없습니다. 신규 사용자에게는 혼동을 줄 수 있습니다.

Do not use bare numbers

Do not use use bare numbers (or hex numbers) as part of your branch naming scheme. Inside tab-expansion of a reference name, git may decide that a number is part of a sha-1 instead of a branch name. For example, my issue tracker names bugs with decimal numbers. I name my related branches CRnnnnn rather than just nnnnn to avoid confusion.

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

If I tried to expand just 15032, git would be unsure whether I wanted to search SHA-1's or branch names, and my choices would be somewhat limited.

Avoid long descriptive names

Long branch names can be very helpful when you are looking at a list of branches. But it can get in the way when looking at decorated one-line logs as the branch names can eat up most of the single line and abbreviate the visible part of the log.

On the other hand long branch names can be more helpful in "merge commits" if you do not habitually rewrite them by hand. The default merge commit message is Merge branch 'branch-name'. You may find it more helpful to have merge messages show up as Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' instead of just Merge branch 'fix/CR15032'.

---

A successful Git branching model by Vincent Driessen has good suggestions. A picture is below. If this branching model appeals to you consider the flow extension to git. Others have commented about flow

Driessen's model includes

• A master branch, used only for release. Typical name master.

• A "develop" branch off of that branch. That's the one used for most main-line work. Commonly named develop.

• Multiple feature branches off of the develop branch. Name based on the name of the feature. These will be merged back into develop, not into the master or release branches.

• Release branch to hold candidate releases, with only bug fixes and no new features. Typical name rc1.1.

Hotfixes are short-lived branches for changes that come from master and will go into master without development branch being involved.

---

My personal preference is to delete the branch name after I’m done with a topic branch.

Instead of trying to use the branch name to explain the meaning of the branch, I start the subject line of the commit message in the first commit on that branch with “Branch:” and include further explanations in the body of the message if the subject does not give me enough space.

The branch name in my use is purely a handle for referring to a topic branch while working on it. Once work on the topic branch has concluded, I get rid of the branch name, sometimes tagging the commit for later reference.

That makes the output of git branch more useful as well: it only lists long-lived branches and active topic branches, not all branches ever.

---

I've mixed and matched from different schemes I've seen and based on the tooling I'm using. So my completed branch name would be:

name/feature/issue-tracker-number/short-description

which would translate to:

mike/blogs/RSSI-12/logo-fix

The parts are separated by forward slashes because those get interpreted as folders in SourceTree for easy organization. We use Jira for our issue tracking so including the number makes it easier to look up in the system. Including that number also makes it searchable when trying to find that issue inside Github when trying to submit a pull request.

---

Why does it take three branches/merges for every task? Can you explain more about that?

If you use a bug tracking system you can use the bug number as part of the branch name. This will keep the branch names unique, and you can prefix them with a short and descriptive word or two to keep them human readable, like "ResizeWindow-43523". It also helps make things easier when you go to clean up branches, since you can look up the associated bug. This is how I usually name my branches.

Since these branches are eventually getting merged back into master, you should be safe deleting them after you merge. Unless you're merging with --squash, the entire history of the branch will still exist should you ever need it.

---

Note, as illustrated in the commit e703d7 or commit b6c2a0d (March 2014), now part of Git 2.0, you will find another naming convention (that you can apply to branches).

"When you need to use space, use dash" is a strange way to say that you must not use a space.
Because it is more common for the command line descriptions to use dashed-multi-words, you do not even want to use spaces in these places.

A branch name cannot have space (see "Which characters are illegal within a branch name?" and git check-ref-format man page).

So for every branch name that would be represented by a multi-word expression, using a '-' (dash) as a separator is a good idea.

---

Following up on farktronix's suggestion, we have been using Jira ticket numbers for similar in mercurial, and I'm planning to continue using them for git branches. But I think the ticket number itself is probably unique enough. While it might be helpful to have a descriptive word in the branch name as farktronix noted, if you are switching between branches often enough, you probably want less to type. Then if you need to know the branch name, look in Jira for the associated keywords in the ticket if you don't know it. In addition, you should include the ticket number in each comment.

If your branch represents a version, it appears that the common convention is to use x.x.x (example: "1.0.0") format for branch names and vx.x.x (example "v1.0.0") for tag names (to avoid conflict). See also: 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