Vincent Driessen 의 div> 성공적인 Git 분기 모델 에는 좋은 제안이 있습니다. 이 분기 모델이 마음에 들면 git에 대한 흐름 확장 을 고려하세요. 다른 사람들은 흐름에 대해 주석을 달았습니다 .

태그 관행

이미 알고 있듯이 Git은 1.0과 같은 커밋 식별자를 제공합니다. -2-g1ab3183하지만 태그가 아닙니다! 태깅은 git 태그로 수행되며 git 태그를 사용하여 생성 된 태그는 git describe 생성하는 커밋 식별자의 기반이됩니다. 다시 말해, Git에서는 브랜치에 태그를 지정하지 않습니다. 커밋에 태그를 지정하는 것입니다. 태그가 커밋에 대한 주석이 달린 포인터라고 말하는 것이 옳습니다.

이를 시연 한 실제 예제를 살펴 보겠습니다.

 /-- [v1.0] v ---.---.---.---S---.---A <-- master \ \-.---B <-- test 

커밋 “S”가 “v1.0″태그로 지정되도록합니다. 이 커밋은 “master”분기와 “test”분기 모두에 있습니다. 커밋 상단에서 " git describe "를 실행하는 경우 ” A “(“마스터 “브랜치의 상단)는 v1.0-2-g9c116e9와 같은 것을 얻을 수 있습니다. 커밋 “B”(일명 “test”브랜치) 위에서 " git describe "를 실행하면 v1.0-2-g3f55e41, 이는 기본 git-describe 구성의 경우입니다. 이 결과는 약간 다릅니다. v1.0-2-g9c116e9는 정렬 된 SHA-1 ID가 9c116e9 인 커밋 중임을 의미하며 v1.0. 태그가 없습니다. v1.0-2!

태그가 “master”브랜치에만 표시되도록하려면 새 커밋을 만들 수 있습니다 (예 : 업데이트 기본값 / 대체 GIT-VERSION-FILE의 버전 정보) “test”분기의 분기 지점 이후. 예를 들어 “test”브랜치에 커밋을 태그하면 “v1.0.3`은”test “에서만 볼 수 있습니다.

참조

배워야 할 유용한 블로그와 게시물을 많이 찾았습니다. 그러나 전문적으로 설명 된 것은 드문 경우입니다. 따라서 @nvie의 성공적인 Git 분기 모델 게시물을 추천하고 싶습니다. 그의 일러스트레이션을 빌 렸습니다. 🙂

댓글

• 1.0-2-g1ab3183 은 git에서 사용할 수있는 정보에서 git describe에 의해 생성 된 식별자이지만 git 식별자라고 부르는 것은 너무 많은 일입니다. Git은 SHA 해시로 식별합니다. 태그와 분기는 git이 추적하는 데 도움이되는 인간 구조입니다. 따라서 태그를 만드십시오. 누군가가 언젠가는 커밋에 대한 편리한 북마크를 찾고 싶어 할 것이라고 생각할 때.
• git 유니버스의 다차원성에 대한 멋진 그림입니다. 아름답습니다. 감사합니다
• 많은 프로젝트에 일부 이 다이어그램에 표시된 차선의 일부 프로젝트는 여기서 개발 및 기능이라고하는 ' 만 필요합니다. 이는 마음대로 배포 할 수있는 웹 앱의 경우 종종 해당됩니다.
• git flow의 작성자조차도 웹 개발과 같은 많은 프로젝트 유형에 더 이상 권장하지 않습니다. 많은 사람들은 대부분의 프로젝트가 필요로하는 것보다 훨씬 더 복잡하다고 생각하여 실행하기가 번거롭고 잘못되기 쉽습니다.스펙트럼의 다른 쪽 끝에서 일부 고급 실무자 옹호 팀은 브랜치를 거의 사용하지 않는 ' 트렁크 기반 개발 '을 사용합니다. 그런 성공적인 프로젝트를 제공합니다. 중급의 경우 " anti-gitflow '