CVS에서 Git으로 이동 : $ Id $ 상당?

간단한 소스 코드 제어 도구에 대해 묻는 많은 질문을 읽었으며 Git은 합리적인 선택처럼 보였습니다. 나는 그것을 실행하고 있으며 지금까지 잘 작동합니다. 내가 CVS에 대해 좋아하는 한 가지 측면은 버전 번호의 자동 증가입니다.

분산 저장소에서는 이것이 의미가 없다는 것을 이해하지만 개발자로서 나는 이와 같은 것을 원하거나 필요로합니다. 이유를 설명하겠습니다.

나는 Emacs를 사용합니다. 정기적으로 타사 패키지 용 Lisp 소스 파일의 새 버전을 살펴 봅니다. 헤더에 따르면 버전 1.3 인 foo.el 파일이 있다고 가정 해 보겠습니다. 최신 버전을 찾아 보면 1.143이나 2.6 또는 그 어떤 것이 든 내가 상당히 뒤쳐져 있다는 것을 압니다.

대신 40 자 해시 두 개가 표시되면 나중에 어떤 것이 있는지 알 수 없거나 얼마나 늦는 지 알 수 없습니다. 내가 얼마나 오래된 지 알기 위해 ChangeLogs를 수동으로 확인해야한다면 정말 싫어할 것입니다.

개발자로서 저는 제 결과물을 사용하는 사람들에게이 예의를 확장하고 싶습니다. 매번 직접 숫자를 늘리거나 타임 스탬프 또는 이와 비슷한 것을 증가시키는 것을 기억하고 싶지 않습니다. 그것은 실제 PITA이며 경험을 통해 알고 있습니다.

그래서 어떤 대안이 있습니까? $ Id : $에 해당하는 항목을 얻을 수없는 경우 원하는 정보를 어떻게 제공 할 수 있습니까?

내 기대는 최종 사용자가 Git을 설치하지 않고 설치하더라도 로컬 리포지토리를 갖지 않을 것이라는 것입니다.

SHA는 버전의 하나의 표현 일뿐입니다 (표준이지만). 이 git describe명령은 다른 사람들을 제공하고 매우 잘 수행합니다.

예를 들어 Java memcached 클라이언트 소스 git describe의 마스터 브랜치에서 실행 하면 다음과 같은 결과가 나타납니다.

2.2-16-gc0cd61a

그것은 두 가지 중요한 것을 말합니다.

1. 2.2 이후이 트리에는 정확히 16 개의 커밋이 있습니다.
2. 정확한 소스 트리가 누구 다른 사람의 복제에 표시 할 수 있습니다.

예를 들어, version해당 번호를 표시하기 위해 소스와 함께 파일 을 패키징했다고 가정 해 보겠습니다 (또는 배포를 위해 모든 콘텐츠를 다시 작성). 패키지 버전이 2.2-12-g6c4ae7a(릴리스가 아니라 유효한 버전) 이라고 가정 해 보겠습니다 .

이제 정확히 얼마나 멀리 당신이 (4 커밋가) 있습니다 뒤에 볼 수 있습니다, 그리고 정확히하는 4 커밋을 볼 수 있습니다 :

# The RHS of the .. can be origin/master or empty, or whatever you want.
% git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a
c0cd61a Dustin Sallings More tries to get a timeout.
8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui
fb326d5 Dustin Sallings Added a test for bug 35.
fba04e9 Valeri Felberg Support passing an expiration date into CAS operations.

지금까지 Git에서 $ Id : $를 지원합니다. 파일 README에 대해 활성화하려면 "README ident"를 .gitattributes에 넣 습니다 . 파일 이름에 와일드 카드가 지원됩니다. 자세한 내용은 man gitattributes 를 참조하십시오.

이것은 OP의 부당한 요청이 아닙니다.

내 사용 사례는 다음과 같습니다.

1. 나는 내 개인 코드에 Git을 사용하므로 다른 사람과 협력하지 않습니다.
2. /usr/local/bin준비가되었을 때 들어갈 수있는 시스템 Bash 스크립트를 거기에 보관합니다 .

동일한 Git 저장소가있는 세 개의 개별 컴퓨터를 사용합니다. /usr/local/bin수동 "diff -u <repo version> <version in / usr / local / bin>"을 수행하지 않고도 현재 파일의 "버전"을 아는 것이 좋습니다 .

부정적인 사람들에게는 다른 사용 사례가 있다는 것을 기억하십시오. 모든 사람이 Git 저장소의 파일이 "최종"위치 인 공동 작업에 Git을 사용하는 것은 아닙니다.

어쨌든, 내가 한 방법은 다음과 같이 저장소에 속성 파일을 만드는 것입니다.

cat .git/info/attributes
# see man gitattributes
*.sh ident
*.pl ident
*.cgi ident

그런 다음 파일 어딘가에 $ Id $를 넣습니다 (나는 shebang 뒤에 넣는 것을 좋아합니다).

커밋. 예상대로 확장이 자동으로 수행되지는 않습니다. 예를 들어, 파일을 다시 복사해야합니다.

git commit foo.sh
rm foo.sh
git co foo.sh

그러면 확장이 표시됩니다. 예를 들면 다음과 같습니다.

$ head foo.sh
#!/bin/sh

# $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $

좋은 정보는 Git 저장소에 대한 ident 문자열을 어떻게 활성화합니까?에 있습니다. .

이것이 Git에 있을지 확실하지 않습니다. Linus 를 인용 하려면 :

"키워드 대체에 대한 전체 개념은 완전히 멍청합니다. 릴리스 트리를 타르볼 등으로 사용하려면 실제 콘텐츠 추적을"외부 "에서 수행하는 것은 사소한 일입니다."

로그를 확인하는 것은 매우 쉽습니다. foo.el의 stable 브랜치를 추적하는 경우 로컬 복사본에없는 stable 브랜치의 로그에 어떤 새로운 커밋이 있는지 확인할 수 있습니다. CVS의 내부 버전 번호를 시뮬레이션하려는 경우 마지막 커밋의 타임 스탬프를 비교할 수 있습니다.

편집 :이를 위해 다른 사람의 스크립트를 작성하거나 사용해야합니다. 물론 수동으로 수행하지 마십시오.

내가 작성한으로 하기 전에 :

모든 사람의 개발 라인이 다른 모든 라인과 다를 수 있기 때문에 Bazaar와 같은 DSCM 도구로는 적절한 버전 번호를 표시하는 자동 생성 Id 태그를 사용할 수 없습니다. 따라서 누군가가 파일의 버전 "1.41"을 참조 할 수 있지만 해당 파일의 버전 "1.41"이 다릅니다.

기본적으로 $ Id $는 Bazaar, Git 및 기타 분산 소스 코드 관리 도구에서 의미가 없습니다.

나는 같은 문제가 있었다. 해시 문자열보다 간단하고 저장소에 연결할 필요없이 도구를 사용하는 사람들이 사용할 수있는 버전이 필요했습니다.

나는 Git 사전 커밋 후크를 사용하여 자동으로 업데이트 할 수 있도록 스크립트를 변경했습니다.

나는 커밋 횟수를 기반으로 버전을 결정합니다. 두 사람이 동시에 커밋 할 수 있고 둘 다 동일한 버전 번호를 커밋하고 있다고 생각하기 때문에 약간의 경쟁 조건입니다.하지만이 프로젝트에 개발자가 많지 않습니다.

예를 들어, Ruby에있는 스크립트를 확인하고 여기에이 코드를 추가합니다. 매우 간단한 코드이므로 다른 언어로 확인하는 경우 다른 언어로 쉽게 이식 할 수 있습니다 (분명히 이것은 텍스트 파일과 같은 실행 불가능한 체크 인에서는 쉽게 작동하지 않습니다.) 나는 추가했다 :

MYVERSION = '1.090'
## Call script to do updateVersion from .git/hooks/pre-commit
def updateVersion
  # We add 1 because the next commit is probably one more - though this is a race
  commits = %x[git log #{$0} | grep '^commit ' | wc -l].to_i + 1
  vers = "1.%0.3d" % commits

  t = File.read($0)
  t.gsub!(/^MYVERSION = '(.*)'$/, "MYVERSION = '#{vers}'")
  bak = $0+'.bak'
  File.open(bak,'w') { |f| f.puts t }
  perm = File.stat($0).mode & 0xfff
  File.rename(bak,$0)
  File.chmod(perm,$0)
  exit
end

그런 다음 스크립트에 명령 줄 옵션 (-updateVersion)을 추가하여 "tool -updateVersion"이라고 부르면 "MYVERSION"값 자체를 수정하는 도구에 대해 updateVersion을 호출 한 다음 종료합니다. 원하는 경우 다른 파일도 열리면 업데이트하십시오).

설정이 완료되면 Git 헤드로 이동하여 실행 가능한 한 줄 bash 스크립트를 .git/hooks/pre-commit.

스크립트는 단순히 Git 디렉토리의 헤드로 변경되고 내 스크립트를 -updateVersion.

-updateVersion으로 스크립트를 실행하는 사전 커밋 스크립트를 체크인 할 때마다 커밋 수에 따라 MYVERSION 변수가 업데이트됩니다. 마법!

$ Keywords $가 필수적인 경우 Mercurial을 대신 사용해 볼 수 있습니까? 원하는 것을 구현하는 hgkeyword 확장이 있습니다. Mercurial은 어쨌든 DVCS로서 흥미 롭습니다.

Git 리포지토리로 수행되는 작업은 tag객체 를 사용하는 것입니다. 이것은 모든 종류의 문자열로 커밋에 태그를 지정하는 데 사용할 수 있으며 버전을 표시하는 데 사용할 수 있습니다. git tag모든 태그를 반환 하는 명령 을 사용하여 저장소에서 해당 태그를 볼 수 있습니다 .

태그를 확인하는 것은 쉽습니다. 예를 들어 태그가있는 경우 다음 v1.1과 같이 분기로 해당 태그를 확인할 수 있습니다.

git checkout -b v1.1

최상위 객체이므로 해당 커밋에 대한 전체 기록을 볼 수있을뿐만 아니라 diff를 실행하고 변경하고 병합 할 수 있습니다.

뿐만 아니라 태그가 있던 브랜치가 메인 라인으로 다시 병합되지 않고 삭제 되어도 태그가 유지됩니다.

내가 올바르게 이해한다면, 마지막으로 업데이트 한 이후 주어진 파일에서 몇 번의 커밋이 발생했는지 알고 싶습니다.

먼저 원격 오리진에서 변경 사항을 가져 오되 master분기에 병합하지 마십시오 .

% git fetch

그런 다음 master브랜치와 원격지 간에 주어진 파일에서 발생한 변경 사항에 대한 로그를 가져옵니다 origin/master.

% git log master..origin/master foo.el

이렇게하면 .NET 파일에 마지막으로 병합 한 이후 원격 저장소에서 발생한 모든 커밋의 로그 메시지가 제공 origin/master됩니다 master.

변경 사항의 개수 만 확인하려면 wc. 다음과 같이 말하십시오.

% git rev-list master..origin/master foo.el | wc -l

사람들이 얼마나 오래되었는지 알 수 있기를 원한다면 Git은 몇 가지 매우 쉬운 방법으로 그들에게 알릴 수 있습니다. 예를 들어 트렁크와 트렁크에서 마지막 커밋 날짜를 비교합니다. 그들은 git cherry자신의 트렁크에없는 커밋이 얼마나 많은 커밋이 발생했는지 확인할 수 있습니다 .

이것이 당신이 원하는 전부라면, 나는 버전 번호없이 그것을 제공 할 방법을 찾을 것입니다.

또한, 나는 당신이 그들이 그것을 원한다고 확신하지 않는 한 누구에게도 예의를 베풀지 않을 것입니다. :)

저장소의 모든 하위 디렉토리에있는 모든 파일에 확장을 적용하려면 다음을 포함하는 파일을 저장소 .gitattributes의 최상위 디렉토리 (즉, 일반적으로 .gitignore파일을 넣는 위치 )에 추가합니다 .

* ident

이를 적용하려면 먼저 파일을 삭제하거나 편집하는 등 파일을 효과적으로 체크 아웃해야합니다. 그런 다음 다음을 사용하여 복원하십시오.

git checkout .

그리고 $Id$다음과 같은 것으로 대체 되어야합니다 .

$Id: ea701b0bb744c90c620f315e2438bc6b764cdb87 $

에서 man gitattributes:

ident

경로에 대해 속성 ident가 설정되면 Git은 Blob 개체의 $ Id $를 $ Id :로 바꾼 다음, 40 자 16 진수 Blob 개체 이름, 체크 아웃시 달러 기호 $가 뒤 따릅니다. 작업 트리 파일에서 $ Id :로 시작하고 $로 끝나는 모든 바이트 시퀀스는 체크인시 $ Id $로 대체됩니다.

이 ID는 파일의 새 버전이 커밋 될 때마다 변경됩니다.

RCS ID는 단일 파일 프로젝트에 적합하지만 다른 경우 $ Id $는 프로젝트에 대해 아무 말도하지 않습니다 (더미 버전 파일에 대해 더미 체크인을 강제하지 않는 한).

여전히 파일 수준 또는 커밋 수준에서 $ Author $, $ Date $, $ Revision $, $ RCSfile $ 등의 등가물을 얻는 방법에 관심이있을 수 있습니다 (일부 키워드가있는 곳에 두는 방법 질문). 이에 대한 답변은 없지만 특히 파일 (현재 Git에 있음)이 RCS 호환 시스템 (CVS)에서 생성 된 경우 업데이트에 대한 요구 사항을 확인합니다.

이러한 키워드는 소스가 Git 저장소와 별도로 배포되는 경우 흥미로울 수 있습니다 (저도 그렇게합니다). 내 솔루션은 다음과 같습니다.

모든 프로젝트에는 자체 디렉토리가 있으며 프로젝트 루트 .version에는 현재 버전을 설명하는 콘텐츠 (소스를 내보낼 때 사용되는 이름) 라는 이름의 텍스트 파일 이 있습니다.

다음 릴리스에서 작업하는 동안 스크립트는 해당 .version번호, 일부 Git 버전 설명자 (예 git describe:) 및 단일 빌드 번호 .build(호스트 및 날짜 포함)를 최종 프로그램에 링크 된 자동 생성 소스 파일로 추출 하므로 찾을 수 있습니다. 어떤 출처에서 언제 만들어 졌는지.

별도의 분기에서 새로운 기능을 개발하고 첫 번째 작업은 문자열에 ( n"next"에 대해 ) 추가하는 것입니다 ( .version같은 루트에서 시작된 여러 분기는 동일한 임시 .version번호를 사용함 ). 릴리스하기 전에 병합 할 분기를 결정합니다 (모두 동일한 .version). 병합을 커밋하기 전에 .version다음 번호로 업데이트합니다 (병합 된 기능에 따라 주 또는 부 업데이트).

당신이 자식이 정보 커밋하려면 접근을 코드에, 당신은 이 거기를 얻기 위해 사전 빌드 단계를 수행 할 수 있습니다. C / C ++ 용 bash에서는 다음과 같이 보일 수 있습니다.

prebuild.sh

#!/bin/bash
commit=$(git rev-parse HEAD)
tag=$(git describe --tags --always ${commit})
cat <<EOF >version.c
#include "version.h"
const char* git_tag="${tag}";
const char* git_commit="${commit}";
EOF

다음과 version.h같이 보입니다.

#pragma once
const char* git_tag;
const char* git_commit;

그런 다음 코드 #include "version.h"및 참조 에서 필요 git_tag하거나 git_commit필요에 따라 어디에서나 필요합니다.

그리고 당신 Makefile은 다음과 같은 것을 가질 수 있습니다.

all: package
version:
  ./prebuild.sh
package: version
  # the normal build stuff for your project

다음과 같은 이점이 있습니다.

• 받고 현재 에 대한 올바른 값 이 관계없이, 분기 체리 따기 및 병합의 빌드를.

이 구현 prepublish.sh에는 다음과 같은 단점이 있습니다.

• git_tag/ git_commit가 변경되지 않은 경우에도 강제로 재 컴파일 합니다.
• 커밋되지 않았지만 빌드에 영향을 미치는 로컬 수정 파일은 고려하지 않습니다.
  • 사용 git describe --tags --always --dirty사례를 포착하는 데 사용합니다.
• 글로벌 네임 스페이스를 오염시킵니다.

prebuild.sh이러한 문제를 피할 수 있는 애호가 는 독자를위한 연습 문제로 남겨집니다.

토큰 교체가 버전 관리 도구가 아닌 빌드 도구에 속한다고 생각하는 사람들의 의견에 동의합니다.

릴리스에 태그를 지정할 때 소스에서 버전 ID를 설정하려면 자동화 된 릴리스 도구가 있어야합니다.

태그 이름 및 기타 관련 정보는 이제 Git의 export-subst기능을 통해 자동으로 파일로 직접 편집 할 수 있습니다 gitattributes(5). 물론 이것은 git archive릴리스를 생성하기 위해를 사용해야 하며, 결과 tar 파일에서만 대체 편집 내용이 표시됩니다.

예를 들어 .gitattributes파일에 다음 행을 넣으십시오.

* export-subst

그런 다음 소스 파일에서 다음과 같은 줄을 추가 할 수 있습니다.

#ident  "@(#)PROJECTNAME:FILENAME:$Format:%D:%ci:%cN:%h$"

그리고 예를 들어 다음과 같이 생성 된 릴리스에서 다음과 같이 확장됩니다 git archive v1.2.0.90.

#ident  "@(#)PROJECTNAME:FILENAME:HEAD -> master, tag: v1.2.0.90:2020-04-03 18:40:44 -0700:Greg A. Woods:e48f949"

Emacs를 사용하기 때문에 운이 좋을 수도 있습니다. :)

나는 우연히이 질문을 우연히 만났고 또한 우연히도 며칠 전에 Lively에서 왔는데 , 이것은 문서에 생생한 Emacs Lisp 조각을 포함 할 수있는 Emacs 패키지입니다. 솔직히 말하지 않았지만이 글을 읽으면서 마음이 떠올랐다.

저는 또한 SCCS, RCS 및 CVS ( %W% %G% %U%) 에서 왔습니다 .

비슷한 도전이있었습니다. 코드를 실행하는 시스템에 어떤 버전의 코드가 있는지 알고 싶었습니다. 시스템은 네트워크에 연결되거나 연결되지 않을 수 있습니다. 시스템에 Git이 설치되어 있거나 설치되어 있지 않을 수 있습니다. 시스템에 GitHub 저장소가 설치되어 있거나 설치되어 있지 않을 수 있습니다.

여러 유형의 코드 (.sh, .go, .yml, .xml 등)에 대해 동일한 솔루션을 원했습니다. Git 또는 GitHub에 대한 지식이없는 사람이 "어떤 버전을 실행하고 있습니까?"라는 질문에 답할 수 있기를 원했습니다.

그래서 저는 몇 가지 Git 명령에 대해 래퍼라고 부르는 것을 작성했습니다. 버전 번호와 몇 가지 정보로 파일을 표시하는 데 사용합니다. 그것은 내 도전을 해결합니다. 도움이 될 수 있습니다.

https://github.com/BradleyA/markit

git clone https://github.com/BradleyA/markit
cd markit

이 문제를 직접 해결하기 위해 커밋 후 후크로 작은 "해킹"을 만들었습니다.

echo | tee --append *
git checkout *

자세한 내용 은 내 블로그의이 게시물에 설명되어 있습니다.