Git으로 숫자 버전 관리 체계를 어떻게 달성합니까?

우리 조직은 SVN에서 Git으로의 이동을 고려하고 있습니다. 이동에 대한 한 가지 주장은 다음과 같습니다.

버전 관리는 어떻게합니까?

NetBeans 플랫폼을 기반으로하는 SDK 배포판이 있습니다. SVN 개정판은 단순한 숫자이므로이를 사용하여 플러그인 및 SDK 빌드의 버전 번호를 확장 할 수 있습니다. Git으로 이동할 때이 문제를 어떻게 처리합니까?

가능한 해결책:

• Hudson의 빌드 번호 사용 (문제 : 실제 Git 버전과 연관시키기 위해 Hudson을 확인해야 함)
• 야간 및 안정적인 버전 수동 업데이트 (문제 : 학습 곡선, 인적 오류)

다른 사람이 비슷한 문제를 겪고 해결했다면 방법을 듣고 싶습니다.

태그 를 사용 하여 커밋을 버전 번호로 표시 하십시오 .

git tag -a v2.5 -m 'Version 2.5'

태그 업스트림 푸시 — 기본적으로 수행되지는 않습니다.

git push --tags

그런 다음 describe 명령을 사용하십시오 .

git describe --tags --long

이것은 다음과 같은 형식의 문자열을 제공합니다.

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag

이것은 나를 위해 몇 가지 프로젝트에서 나왔습니다. 지금까지 내가 가진 최고의 솔루션은 다음과 같은 버전 번호를 생성하는 것입니다.

xy <커밋 수> .r <git-hash>

일반적으로, 그것은 주요 개정 번호를 얻기 위해 약간의 정적 파일 또는 태그의 조합을 사용하여 우리의 빌드 시스템에 의해 생성 된 것 git rev-list HEAD | wc -l(빠른 사용하는 것보다했다 git log), 그리고 git rev-parse HEAD. 추론은 다음과 같습니다.

1. 높은 수준의 버전 관리를 명시 적으로 수행 할 수있는 기능이 필요했습니다 (iexy).
2. 병렬 개발이 진행될 때 동일한 버전 번호를 생성하지 않아야했습니다.
3. 버전의 출처를 쉽게 추적하고 싶었습니다.
4. 병렬 라인이 병합되었을 때, 우리는 새로운 버전이 브랜치 중 하나보다 더 높은 해상도를 갖기를 원했습니다.

수 2는 대부분의 사람들에게 보이지 않는, 그러나입니다 정말 중요하고, 정말 분산 소스 제어 어렵다. SVN은 단일 개정 번호를 제공하여이를 지원합니다. 커밋 수는 가능한 한 근접한 것으로 밝혀졌으며 마술은 # 4를 해결합니다. 가지가있는 경우에도 여전히 고유하지는 않습니다.이 경우 해시를 추가하여 # 3을 깔끔하게 해결합니다.

이것의 대부분은 Python의 pip를 통한 배포를 수용하는 것이 었습니다. 이것은 pip install병렬 개발 중에 약간 이상 할 수 있음을 보장했습니다 (즉, 다른 지점에있는 사람들의 패키지가 섞일 수는 있지만 결정적 방식으로), 병합 후 모든 것이 정리되었습니다. 노출 된 리베이스 또는 수정의 존재를 제외하고는 위의 요구 사항에 매우 효과적이었습니다.

궁금한 점이 있다면, 파이썬 패키징이 버전 번호에서 문자를 처리하는 방법에 약간의 기이함이 있기 때문에 해시 앞에 r을두기로 선택했습니다 (즉, ae가 0보다 작으므로 "1.3.10.a1234"< "1.3.10"< "1.3.10.1234").

약간 과잉 일 수도 있지만 어떻게해야하는지 알려 드리겠습니다.

우리는 이것 과 매우 유사한 분기 구조를 사용합니다 .

Hudson은 "개발"분기를 작성하고 0부터 시작하여 빌드 번호를 증가시킵니다. 빌드 번호는 각 프로젝트마다 고유하며 버전 관리에서 태그가 지정됩니다. 그 이유는 예를 들어 어떤 개발 브랜치 빌드 42가 나왔는지를 정확하게 알 수 있도록하기 위해서입니다 (각 프로젝트는 여러 팀이 프로젝트의 다른 측면에서 작업 할 수 있기 때문에 각 프로젝트에는 여러 개의 브랜치가 동시에있을 수 있습니다).

특정 빌드가 릴리스하기에 충분하다고 판단하면 해당 빌드를 트리거 한 커밋에 릴리스 버전 번호가 표시되며 마케팅에 의해 결정됩니다. 이는 개발자 팀이 최종 버전 번호가 무엇인지 신경 쓰지 않고 마케팅이 버전 번호를 자유롭게 섞을 수 있음을 의미합니다. 최종 버전 번호와 빌드 번호는 모두 출시 된 제품에 있습니다.

예 : 2.1.0 빌드 1337

즉, 특정 제품 릴리스의 경우 마지막으로 작업 한 팀을 알 수 있으며 필요한 경우 릴리스로 이어지는 모든 커밋에 대해 git을 쿼리하여 문제를 진단 할 수 있습니다.

체크인시 저장된 디렉토리 트리에있는 모든 파일의 SHA1 해시를 해싱하는 버전이 식별됩니다. 이 해시는 전체 체크인을 읽을 수 있도록 부모 체크인의 해시와 함께 저장됩니다.

GIT-VERSION-GEN을 통해 'git-describe'를 사용하는 프로세스와 릴리스에 태그를 지정할 때 빌드 프로세스를 통해이를 추가하는 방법을 살펴보십시오.

다음은 원하는 것을 얻는 방법에 대한 예제를 제공하는 멋진 블로그입니다.

http://cd34.com/blog/programming/using-git-to-generate-an-automatic-version-number/

Jon Purdy는 올바른 아이디어를 가지고 있습니다. git flow뿐만 아니라 이러한 지점의 실제 관리가 쉬워지고 지점 관리는로 이동하기위한 논쟁입니다 git.

의는의 기본 개요부터 시작하자 git당신이에서오고있어 이후, svnDi의 git관점. git다음을 고려하십시오 .

master--...............-.....-..............-
        \             /     /              /
         ---develop---------............../
                            \            /
                             --feature---

위에서,로 분기 master하고 develop(로 표시 \) 분기 develop로 feature분기합니다. 분기를 따라 /커밋 ( -)을 사용하여 해당 분기를 백업 (으로 표시 )으로 병합합니다 . (커밋이 없지만 병합이 올바른 방법 인 경우 다음 커밋이 다음 커밋 .임을 나타내는 표시기 가 있습니다 -).

충분히 쉽다. 메인 릴리스에 핫픽스가 있으면 어떻게합니까?

master--...............-.....-................-...........-.........-
        \             /     /                / \         /|        /
         \           /     /                /   -hotfix-- V       /
          ---develop---------............../..............-...----
                             \            / \             V   /
                              --feature---   --feature2...----

에서 develop분기했습니다 master. 에서 발견 된 버그는에서 master분기하여 수정 한 master후 다시 병합하여 수정되었습니다 master. 우리는 합병 master에 develop, 다음 develop에feature2 에서 새 코드를 압연하는, hotfix이 지점에.

로 feature2다시 병합하면 develop이력에 develop와가 포함 됩니다 hotfix. 마찬가지로, develop로 병합 feature2에서 새 코드 master때문에 병합, develop다시 master그것을 기반으로로 그 커밋에 차질없이 일어날 master그 시간대로에서 분기 한 경우에 master그 시점에서.

여기 또 다른 방법이 있습니다.

master--..........-........-
        \        /\       /
         ---1.0--  --1.1-- 

귀하의 1.0 릴리스는 tagged- 얻을 1.0.1, 1.0.2, 1.0.3, 등.

이제 여기 트릭이 있습니다. 1.0에서 버그를 발견했으며 1.1, 1.2 및 1.3에 영향을 미칩니다. 너 뭐하니?

최신 또는 가장 빠른 유지 보수 릴리스를 분기하고 수정하십시오. 그럼 당신은 당신의 새로운 병합 hotfix에 지점 1.3에 - 그리고 1.2, 1.1하고 1.0. 각 유지 관리 버전 분기에서 분기하지 마십시오. 병합하지 않는 1.0으로 master또는 병합 master뒷면에 1.0. 하나의 hotfix브랜치를 가져와 모든 버전 브랜치에 병합하십시오. 충돌이 있으면 알려줄 것입니다. 코드가 올바른지 확인하십시오 ( git diff친구).

이제 특정 변경 사항이 모든 곳에 적용됩니다. 계보는 분기되어 있지만 괜찮습니다. 우연이 아닙니다. 1.3헤드에 1.3.17 태그를 지정하고 에서 분기 된 모든 진행중인 피쳐에 병합 한 다음 계속하십시오 1.3.

git flow확장은 이러한 유지 보수, 기능 및 핫픽스 가지를 관리 할 수 있습니다. 워크 플로우가 다운되면 이것은 사소한 것이며 소스 코드 관리에서 많은 문제를 일으 킵니다.

나는 이것이 프로그래밍 팀에서 수행되는 것을 보았지만 프로그래머로서 그렇게 깊이 일하지는 않았으므로 여전히 일상적인 워크 플로우를 둘러보고 있습니다.

"키워드"의 7.2 "Git 속성"섹션에있는 Pro Git 확장 부분에는 RCS 스타일 키워드를 생성하기 위해 얼룩 및 청소 필터를 사용하는 좋은 예가 포함되어 있습니다. 규칙에 따라 형식화되고 계산 된 코드에 some-version-string 을 임베드하는 데 동일한 기술을 사용할 수 있습니다 . 당신은 여전히 수 있습니다 사용 응시 지점으로,하지만 당신은 더 이상 적절한 형태로 변환 및 2.5.14 v2.5-14-feebdaed, 예를 들어, 깨끗한에서 얻을 수있는 가능성이git describe