일부 버전 제어 시스템, 예를 들어 PERFORCE는 CL을 단순한 정수로 유지하므로 동일한 분기에서 두 개의 다른 CL을 조사하면 어떤 CL이 먼저 병합되었는지 쉽게 알 수 있습니다. 그러나 Git의 경우, CL/short CL은 긴 16 진 문자열로, 인간의 눈으로도 쉽게 비교할 수 없습니다. 이 문제를 해결할 방법이 있습니까?사람이 읽을 수있는/비슷한 git change IDs
나는 두려워하지 않습니다. 시스템의 분산 된 특성은 단조롭게 증가하는 "개정 번호"를 배제합니다. 만약 당신과 지구 반대편의 다른 누군가가 정확히 같은 시간에 패치를 저지하려고한다면, 버전은 이고 누구는 n+1입니까? 이러한 종류의 동기화는 수정 번호를 할당 할 수있는 단일 중앙 서버가있는 경우에만 가능합니다. 그것은 배포되는 것에 대해 지불 할 대가입니다.
그러나 기술적 인 해결책은 없지만 사회적 해결책이 있습니다. 적절한 지사 이름, 적절한 태깅은 프로젝트의 진행 상황을 이해하는 데 도움이됩니다. git branch --merged 및 --no-merged은 병합되는 지점과 그렇지 않은 지점에 대한 세부 정보를 제공합니다.
(정답이며 upvoted입니다.) 태그를 사용할 때'git describe'도 사용할 수 있습니다. 이것은 다소 인간 친화적 인 숫자를 계산하려고 시도하며, '
설명, 분기, 태그 및 기타 여러 가지 결과는 [treeish] (http://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git#18605496)의 예입니다.) s 안에 자식. –
실제로 그들은 "커미셔닝"을하고 있지만 트리가 필요한 곳이라면 커밋을 식별하는 모든 것이 트리로 처리됩니다. 'git show'와 같은 몇 가지 명령은 커밋에 액세스합니다. 이 경우 gitrevisions의'^ {tree}'접미어를 사용하여 커밋 ID가 해당 트리 ID로 변환되도록 할 수 있습니다. – torek
아니요. git의 SHA-1 해시는 40 자 문자열입니다. 파일의 내용을 기반으로 계산됩니다. git olny는 SHA-1을 데이터베이스에 저장합니다. 따라서 인간의 눈에는 읽을 수 없습니다.
git의 내역을 확인하려면 git log --oneline --decorate --graph --all이 보이지 않아야합니다.
이 때문에 Git의 모든 커밋에는 _message_ 태그가 포함되어 있고 태그도 가능합니다. –
누가 누군가를 투표했는지 모르겠다. –
그것이 가치있는 일은 내가 아니 었습니다. –