작은 버그 수정 및 작은 기능 (표 번호별로 지점 이름 지정 또는 기능 설명별로 이름 지정) 중 어떤 것이 더 낫습니까?

나는 적절한 브랜치 명명에 대한 나의 리드와 의견의 불일치가 있습니다 (물론, 물론). 이는 장기 실행 기능 분기가 아닌 버그 수정 및 작은 기능 분기에 적용됩니다. 장기 실행 기능 분기의 경우 사람이 읽을 수있는 이름이 더 좋다는 데 동의합니다. 다음은 두 가지 관점입니다.

나의 것:

팀 및 티켓 번호에 따라 지점 이름을 지정하는 것이 좋습니다. 발권 시스템에서 쉽게 찾을 수 있고 입력하기가 더 쉽습니다. 또한 티켓에 대한 히스토리 정보를 찾을 때 GIT에서 관련 지점을 쉽게 찾을 수 있습니다.

예:

team-name/12345
team-name/53719

그의:

특징 / 기능에 따라 분기 이름 지정 자동 완성이 쉬워지고 개별 숫자보다 기억하기 쉽습니다.

예:

team-name/fix-that-sql-bug
team-name/expand-http-parser

내가 제공 한 타협은 다음과 같습니다.

team-name/12345-fix-that-sql-bug

그러나 그는 GIT 자동 완성을 망쳐 놓기 때문에 이것을 좋아하지 않습니다.

이것이 주로 의견에 근거한 것이라면, 이것이 SO에 더 적합한 방법에 대한 안내를 자유롭게 보내주십시오.

이 경우 숫자와 설명이 모두있는 명명 규칙을 타협 할 수있는 것 같습니다.

예:

팀 이름 / (12345) 수정-그 -SQL- 버그

팀 이름 / (53719)-확장 -http- 파서

여기에는 정답이 없으며 관점에 따라 주관적입니다.

그러나 두 가지 모두 타협하면 두 가지 이점을 모두 누릴 수 있습니다. 팀에 비슷한 의견이있을 때이 점을 염두에 두십시오.

편집하다:

자동 완성 문제를 처리하기 위해 번호가 매겨진 ID를 괄호 안에 넣을 수 있습니다.이 방법으로 항상 분기를 입력 할 때 (분기를 볼 수 있습니다.이 목록에서 번호가 매겨진 ID와 설명을 볼 수 있습니다. 몇 개의 숫자, 탭을 입력하면됩니다.

모두가 동의하고 이해하는 일관된 시스템이있는 한 실제로 중요하지 않습니다.

티켓 번호를 사용하면 어느 지점에서 작업해야하는지 쉽게 기억할 수 있습니다. 설명이 아닌 이슈 번호와 직접 연결되므로 설명 만하는 것은 어떤 특정 문제를 기억하기가 더 어려워지고 모호하지 않도록 긴 바람을 피울 수 있습니다.

team-name/bug-that-has-specific-circumstances-to-occur-and-takes-alot-to-describe

자동 완성 기능을 활용하기 위해 무언가를 명명하는 것은 어리석은 일입니다.

나는 버그 추적기에 대한 링크가 중요하다는 것에 동의합니다 (좋은 단어보다 더 중요합니다. 두 단어로 해결되지 않는 지점에 의해 해결되는 문제를 정확하게 정의하므로 동시에 사람들을 기대하지 않는 유용성) 버그 # 7312와 # 7213의 차이점을 알고 싶습니다. 또한 사람들이 매번 숫자를 완벽하게 얻을 것으로 기대하지 못했습니다. 언젠가 누군가 7213에 대해 7312를 잘못 읽거나 잘못 입력했기 때문에 잘못된 지점에 커밋 할 것입니다.

따라서 분기로 번호를 매기고 점검 역할을하기 위해 매우 짧은 텍스트 설명을 추가하십시오. 어쨌든 분기의 텍스트 (예 : "bug-fix-for-server"또는 "fix-bug-for-server")를 알아야하므로 자동 완성이 지워집니다. f 또는 b로 시작하면!)