git 버전을 빌드 번호로 통합합니까?

동료와 나는 차례대로 현재 git 저장소에서 파생 된 버전을 빌드 할 때마다 코드에 통합하는 문제 / 장점에 대해 토론하고 토론했습니다.

장점은 다음과 같습니다.

• 버전 번호를 업데이트 할 때 사람의 실수에 대해 걱정할 필요가 없습니다.
• 장치에서 찾은 것과 장치에서 파생 된 소스 코드 간의 추적 성

(우리를 위해) 발생한 문제는 다음과 같습니다.

• IDE 파생 빌드 시스템 (예 : MPLABX)은 이러한 종류의 후크를 어디에 두어야하는지 파악하기 어렵게 만들 수 있습니다 (그리고 결국에는 매우 치즈를 can 수 있습니다)
• 실제로 이것을 빌드 스크립트 / makefile에 통합하기위한 추가 작업
• 특정 빌드 접근 방식 (예 : XCode 및 다른 MPLABX로 빌드하는 경우)에 연결하면 다운 스트림 놀라움이 발생할 수 있습니다.

그래서 우리는 다른 사람들이이 토론에 참여한 곳이 궁금합니다. 토론이 일화가되기가 정말 쉽습니다. 엔드-투-엔드 자동화를 고집하는 많은 사람들이 있습니다. 그리고 토론의 반대편에는 위험을 감수하면서 가장 쉬운 일을하는 사람들이 많이 있습니다.

어느 쪽이 착륙하는 것이 가장 좋은지에 대한 합리적인 대답이 있습니까?

우리는 사용 설명 GIT 버전 태그. 흐름은 기본적으로 다음과 같습니다.

• 현재 작업중인 버전에 대한 태그 생성 (예 : v1.1.2)
• 모든 빌드 실행 git describe
• 배송 할 때 태그 이름을 사용하십시오

git describe태그 이름, 태그 이후의 커밋 수 및 태그의 해시를 제공합니다. 샘플 태그는 다음과 같습니다.

v1.1.2-6-a3b27gae

이는 개발자가 해시를 얻는 이점이 있으므로 빌드간에 문제가 발생하면 개발자가 변경 사항을 쉽게 파악할 수 있습니다. 또한 관리하기가 멍청합니다. 팀 리더가 새로운 버그 수정 브랜치에서 태그를 생성하고 푸시하게하면 빌드 시스템이 나머지를 처리하게됩니다.

사용자가 버전 번호를 쉽게 이해할 수 있도록 해시 (및 빌드 번호)를 제거합니다. 우리는 이것이 릴리스를 엔지니어링 할 때 여전히 충분한 관련 정보를 제공하는 동시에 두 가지 이점을 모두 제공한다는 것을 알았습니다.

현재 약간 더 복잡한 버전이 있지만 아이디어는 여전히 남아 있습니다.

우리는 SVN 상점 이었기 때문에이 수학은 쉬웠습니다. 빌드 번호는 SVN rev였습니다. 우리는 DCVSes로 이사를 시작할 때 이것을 계속하려고했지만 몇 가지 이유로 실패했습니다.

먼저, rev 69bc333bc8d8이 rev 25b0f0d1052c 이전, 이후 또는 동시인지 여부를 누가 알 수 있습니까? 적어도 101이 100 이후임을 알았을 때 SVN 시스템에 비해 상황이 거의 없습니다. 둘째, DCVS 소스 제어의 특성으로 인해 후속 빌드가 동일한 공을 발전시키지 못할 때 여러 가지 방식으로 비선형이됩니다.

마지막으로 빌드 서버를 사용하여 빌드 번호를 배포하고 처리 할 수있는 능력을 갖추 었으므로 빌드 번호를 배포했습니다.

C # DLL의 Visual Studio 빌드 시스템에 대해 다음 구성표를 사용하여 버전 번호를 자동으로 생성합니다 (역사적으로 배포가 올바르게 수행되지 않는 문제가 있었으므로 올바른 버전의 배포를 보장하는 확실한 방법이 필요했습니다).

• 주요-하드 코딩 1, 일반적으로 비즈니스 측에서 결정
• 부-하드 코딩 된 0, 일반적으로 비즈니스 측에서 결정
• 개정-2010 년 1 월 1 일 이후의 일수 (또는 기타 임의의 시작일)
• 빌드-자정 이후 초 수의 절반 (16 비트 부호없는 숫자이므로)

이것은 당신이 가지고 놀 수있는 2 개의 16 비트 부호없는 숫자를 가지고 있다고 가정합니다. 더 작은 숫자를 사용하는 동등한 시스템을 만드는 것도 가능합니다.

또한 숫자가 아닌 필드는 메타 데이터로 첨부 할 수 있으면 유용 할 수 있습니다. 예를 들어 git 버전 번호를 Informational Version 번호로 추가하십시오.

git status, log 및 diff의 출력을 실행 파일에 직접 연결하고 있습니다. 그런 다음 인쇄 할 수있는 옵션이 있습니다. 장점은 바이너리가 만들어진 브랜치를 파악할 수있을뿐만 아니라 커밋되지 않은 소스 코드 변경 사항도 포함 할 수 있다는 것입니다. 참조하십시오 :

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

이 3 개의 파일을 사용하여 자신의 SCM 상태 라이브러리를 만들 수 있어야합니다.

자동 수정 사용을 권장합니다 .

c 스타일 헤더 와 같은 다양한 형식으로 출력을 얻을 수 있습니다 .

또한 누가 빌드하고 있는지, 어떻게하는지에 상관없이 tarball에서 빌드하더라도 항상 동일한 버전 정보를 얻을 수 있도록 몇 가지 예 (contribs dir에)가 있습니다.

또한, 이외에부터 gitAutorevision와 함께 작동 svn하고 hg당신이 그것을 설정 한 후에 너무 많이 변경하지 않고 SVN에서 멀리 전환 쉬워집니다.