힘내 분기 및 태깅 모범 사례
답변:
한마디로 : 모범 사례는 브랜치 아웃, 자주 병합 및 항상 동기화 유지 입니다.
마스터 브랜치와 별도의 브랜치에 코드를 유지하는 것에 대한 명확한 규칙이 있습니다.
- 주요 또는 파괴적인 변경을 구현하려고합니다.
- 사용하지 않을 수도있는 몇 가지 사항을 변경하려고합니다.
- 제대로 작동하지 않는 것을 실험하고 싶습니다.
- 당신이 가지를하라는 지시를 받으면, 다른 사람들은 그들이 주인에게해야 할 일이있을 수 있습니다
경험적으로, 분기 후 마스터 분기와 동기화 상태를 유지해야합니다. 결국 마스터로 다시 병합해야하기 때문입니다. 다시 병합 할 때 복잡한 복잡한 충돌을 피하려면 자주 커밋하고 자주 병합해야합니다.
따라야 할 모범 사례
성공적인 힘내 분기 모델 에 의해 빈센트 Driessen은 좋은 제안이있다. 이 브랜칭 모델이 매력적이라면 git 흐름 확장을 고려하십시오 . 다른 사람들은 흐름에 대해 언급했습니다 .
태그 지정 사례
아시다시피, Git은 1.0-2-g1ab3183과 같은 식별자를 커밋하지만 태그는 아닙니다! 태깅은 git 태그를 사용하여 수행되며 git 태그를 사용하여 생성 된 태그는 git describe가 생성하는 커밋 식별자의 기본입니다. 다시 말해, Git에서는 브랜치를 태그하지 않습니다. 커밋에 태그를 지정하고 있습니다. 태그는 커밋에 대한 주석이 달린 포인터라고 말하는 것이 맞습니다.
그것을 보여주는 실제적인 예를 보자.
/-[v1.0]
V
---.---.---.--- S ---.--- A <-마스터
\
\ -.--- B <-테스트
'S'커밋을 'v1.0'태그로 커밋합시다. 이 커밋은 'master'지점과 'test'지점에 있습니다. 커밋 'A'( '마스터'분기의 상단)에서 " git describe " 를 실행 하면 다음과 같은 결과가 나타납니다 v1.0-2-g9c116e9. 커밋 'A'(일명 'test'브랜치) 위에서 "git describe"를 실행하면 다음과 같은 v1.0-2-g3f55e41결과가 나옵니다. 기본 git-describe 구성의 경우입니다. 이 결과는 약간 다릅니다. v1.0-2-g9c116e9즉, 정렬 된 SHA-1 id의 9c116e9태그 뒤에 2 개의 커밋이 있음을 커밋 v1.0합니다. 태그가 없습니다 v1.0-2!
태그가 '마스터'브랜치에만 나타나도록하려면 'test'브랜치의 브랜치 지점 이후에 새로운 커밋 (예 : GIT-VERSION-FILE의 기본 / 대체 버전 정보 만 업데이트)을 만들 수 있습니다. 예를 들어 'v1.0.3'을 사용하여 'test'브랜치에 커밋을 태그하면 'test'에서만 볼 수 있습니다.
참고 문헌
많은 유용한 블로그와 정보를 얻을 수있었습니다. 그러나 전문적으로 묘사 된 것은 드문 것입니다. 따라서 @nvie 의 게시물- 성공적인 Git 분기 모델 을 추천하고 싶습니다. 나는 그의 그림을 빌렸다 :)
동시에 두 가지 버전의 저장소가있는 경우 분기가 사용됩니다. 태그는 리포지토리에서 특정 시점을 표시하는 방법입니다.
출시 된 버전을 표시하려면 태그를 추가해야합니다. 그런 다음 해당 릴리스의 버그를 수정해야하는 경우 태그에서 분기를 작성합니다.
HEAD (또는 다른 분기)로 다시 병합 된 분기 만 삭제하려고합니다.