Что такое эквивалент Git для номера версии?

Мы используем SVN на работе, но для моих личных проектов я решил использовать Git. Поэтому вчера я установил Git, и мне интересно, что такое номер версии эквивалент в Git.

Предположим, что мы работаем над версией 3.0.8, и каждое исправление ошибок имеет свой номер редакции, который мы можем использовать, когда мы говорим об этом исправлении ошибок. Поэтому, если я помечаю код в Git до 3.0.8, что тогда я могу использовать как номер ревизии или какой-либо другой более подробный вид идентификации? Я считаю, что хэш не очень удобен для людей.

ОТВЕТЫ

Ответ 1

Хорошие или плохие новости для вас, этот хэш - номер ревизии. У меня также были проблемы с этим, когда я переключил SVN на git.

Вы можете использовать "тегирование" в git, чтобы пометить определенную ревизию как "выпуск" для определенной версии, что упростит обращение к этой ревизии. Ознакомьтесь с этим сообщением .

Главное, чтобы понять, что git не может иметь номера версий - подумайте о децентрализованной природе. Если пользователи A и B оба фиксируют свои локальные репозитории, как можно git назначить порядковый номер ревизии? A не знает B, прежде чем они нажимают друг на друга изменения.

Еще одна вещь, на которую нужно обратить внимание - это упрощенное ветвление для ветвей исправления:

Начните с выпуска: 3.0.8. Затем, после этого релиза, сделайте следующее:

git branch bugfixes308

Это создаст ветку для исправлений. Оформить покупку:

git checkout bugfixes308

Теперь сделайте необходимые изменения в исправлении.

git commit -a

Зафиксируйте их и вернитесь к ведущей ветке:

git checkout master

Затем вставьте те изменения из другой ветки:

git merge bugfixes308

Таким образом, у вас есть отдельная ветка исправления для конкретной версии, но вы по-прежнему перетаскиваете исправления ошибок в свой основной ствол dev.

Ответ 2

С современным Git (1.8.3.4 в моем случае) и без использования ветвей вы можете сделать:

$ git rev-list --count HEAD
68

Ответ 3

Команда git describe создает немного более понятное для человека имя, которое ссылается на конкретную фиксацию. Например, из документации:

С чем-то вроде git.git текущего дерева, я получаю:

[[email protected] git]$ git describe parent
v1.0.4-14-g2414721

то есть. текущая глава моей "родительской" ветки основана на версии 1.0.4, но поскольку она содержит несколько коммитов, то описание добавляет количество дополнительных коммитов ( "14" ) и сокращенное имя объекта для самого коммита ( "2414721" ) в конце.

Пока вы используете специально названные теги для тегов конкретных выпусков, это можно считать примерно эквивалентным SVN "номер версии".

Ответ 4

Другие плакаты правы, нет "номера ревизии".

Я думаю, что лучший способ - использовать теги для "выпусков"!

Но я использовал следующие поддельные номера ревизий (только для клиентов, чтобы видеть изменения и прогресс, поскольку они хотели иметь одинаковые увеличенные версии от git, поскольку они используют подрывной деятельностью).

Показывать текущую ревизию "HEAD", используя это:

git rev-list HEAD | wc -l

Но что, если клиент скажет мне, что в "ревизии" 1302 есть ошибка?

Для этого я добавил следующее в раздел [alias] моего файла ~/.gitconfig:

show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'

с помощью git show-rev-number 1302 затем напечатает хэш для "ревизии":)

Я сделал сообщение Blog Post (на немецком) об этой "технике" некоторое время назад.

Ответ 5

Git не имеет той же концепции номеров ревизий, что и подрывная. Вместо этого каждый снимок, сделанный с фиксацией, помечен контрольной суммой SHA1. Зачем? Существует несколько проблем с запуском revno в системе управления распределенной версией:

Во-первых, поскольку разработка не является линейной вообще, привязка числа довольно сложна, так как проблема должна решаться таким образом, чтобы удовлетворить ваши потребности в качестве программиста. Попытка исправить это путем добавления числа может быстро стать проблематичной, когда число не ведет себя так, как вы ожидаете.

Во-вторых, номера версий могут быть сгенерированы на разных машинах. Это делает синхронизацию чисел намного сложнее - тем более, что связь является односторонней; вы даже не можете иметь доступ ко всем машинам, имеющим репозиторий.

В-третьих, в git, несколько внедренном ныне несуществующей системой OpenCM, личность фиксации (что является фиксацией) эквивалентна ее имени (SHA-идентификатор). Эта концепция именования = идентичность очень сильна. Когда вы сидите с именем фиксации в руке, он также идентифицирует фиксацию неприступным образом. Это, в свою очередь, позволяет вам проверить все свои фиксации на первый начальный для коррупции с помощью команды git fsck.

Теперь, поскольку у нас есть DAG (Directed Acyclic Graph) изменений, и они составляют текущее дерево, нам нужны некоторые инструменты для решения вашей проблемы: как мы различаем разные версии. Во-первых, вы можете опустить часть хэша, если данный префикс, 1516bd, однозначно идентифицирует вашу фиксацию. Но это тоже надуманно. Вместо этого, трюк заключается в использовании тегов и/или ветвей. Тег или ветвь сродни "желтой палочке", которую вы прикрепляете к данному фиксатору SHA1-id. Метки, по сути, должны быть не движущимися, тогда как ветка будет двигаться, когда к ее ГОЛОВАМ будут сделаны новые коммиты. Существуют способы ссылки на фиксацию вокруг тега или ветки, см. Справочную страницу git -rev-parse.

Обычно, если вам нужно работать с определенной частью кода, эта часть претерпевает изменения и должна быть как таковая веткой с именем темы высказывания. Создание большого количества веток (20-30 на программиста не является неслыханным, с некоторыми из 4-5 опубликованных для других, для работы) является трюком для эффективного git. Каждый кусочек работы должен начинаться как его собственная ветвь, а затем быть объединенным, когда он будет протестирован. Неопубликованные ветки могут быть полностью переписаны, и эта часть разрушающей истории является силой git.

Когда изменение принимается мастером, оно несколько замерзает и становится археологией. В этот момент вы можете пометить его, но чаще ссылка на конкретный коммит выполняется в трекере ошибок или контролере ошибок через сумму sha1. Теги, как правило, зарезервированы для ударов версии и точек ветвления для ветвей обслуживания (для старых версий).

Ответ 6

Если вам интересно, я автоматически управлял номерами версий из git infos здесь в формате

<major>.<minor>.<patch>-b<build>

где build - общее количество коммитов. Вы увидите интересный код в Makefile. Вот соответствующая часть для доступа к другой части номера версии:

LAST_TAG_COMMIT = $(shell git rev-list --tags --max-count=1)
LAST_TAG = $(shell git describe --tags $(LAST_TAG_COMMIT) )
TAG_PREFIX = "latex-tutorial-v"

VERSION  = $(shell head VERSION)
# OR try to guess directly from the last git tag
#VERSION    = $(shell  git describe --tags $(LAST_TAG_COMMIT) | sed "s/^$(TAG_PREFIX)//")
MAJOR      = $(shell echo $(VERSION) | sed "s/^\([0-9]*\).*/\1/")
MINOR      = $(shell echo $(VERSION) | sed "s/[0-9]*\.\([0-9]*\).*/\1/")
PATCH      = $(shell echo $(VERSION) | sed "s/[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/")
# total number of commits       
BUILD      = $(shell git log --oneline | wc -l | sed -e "s/[ \t]*//g")

#REVISION   = $(shell git rev-list $(LAST_TAG).. --count)
#ROOTDIR    = $(shell git rev-parse --show-toplevel)
NEXT_MAJOR_VERSION = $(shell expr $(MAJOR) + 1).0.0-b$(BUILD)
NEXT_MINOR_VERSION = $(MAJOR).$(shell expr $(MINOR) + 1).0-b$(BUILD)
NEXT_PATCH_VERSION = $(MAJOR).$(MINOR).$(shell expr $(PATCH) + 1)-b$(BUILD)

Ответ 7

Функция A Bash:

git_rev ()
{
    d=`date +%Y%m%d`
    c=`git rev-list --full-history --all --abbrev-commit | wc -l | sed -e 's/^ *//'`
    h=`git rev-list --full-history --all --abbrev-commit | head -1`
    echo ${c}:${h}:${d}
}

выводит что-то вроде

$ git_rev
2:0f8e14e:20130220

Это

commit_count:last_abbrev_commit:date_YYmmdd

Ответ 9

Это то, что я сделал в своем make файле на основе других решений. Обратите внимание, что это не только дает вашему коду номер версии, но также добавляет хеш, который позволяет воссоздать выпуск.

# Set the source control revision similar to subversion to use in 'c'
# files as a define.
# You must build in the master branch otherwise the build branch will
# be prepended to the revision and/or "dirty" appended. This is to
# clearly ID developer builds.
REPO_REVISION_:=$(shell git rev-list HEAD --count)
BUILD_BRANCH:=$(shell git rev-parse --abbrev-ref HEAD)
BUILD_REV_ID:=$(shell git rev-parse HEAD)
BUILD_REV_ID_SHORT:=$(shell git describe --long --tags --dirty --always)
ifeq ($(BUILD_BRANCH), master)
REPO_REVISION:=$(REPO_REVISION_)_g$(BUILD_REV_ID_SHORT)
else
REPO_REVISION:=$(BUILD_BRANCH)_$(REPO_REVISION_)_r$(BUILD_REV_ID_SHORT)
endif
export REPO_REVISION
export BUILD_BRANCH
export BUILD_REV_ID

Ответ 10

Проблема с использованием хеша git в качестве номера сборки заключается в том, что он не монотонно возрастает. OSGi предлагает использовать отметку времени для номера сборки. Похоже, что количество коммитов в ветку может быть использовано вместо числа подрывной или принудительной замены.

Ответ 11

Я написал некоторые утилиты PowerShell для получения информации о версии из Git и упрощения тегов

: Get-LastVersion, Get-Revision, Get-NextMajorVersion, Get-NextMinorVersion, TagNextMajorVersion, TagNextMinorVersion:

# Returns the last version by analysing existing tags,
# assumes an initial tag is present, and
# assumes tags are named v{major}.{minor}.[{revision}]
#
function Get-LastVersion(){
  $lastTagCommit = git rev-list --tags --max-count=1
  $lastTag = git describe --tags $lastTagCommit
  $tagPrefix = "v"
  $versionString = $lastTag -replace "$tagPrefix", ""
  Write-Host -NoNewline "last tagged commit "
  Write-Host -NoNewline -ForegroundColor "yellow" $lastTag
  Write-Host -NoNewline " revision "
  Write-Host -ForegroundColor "yellow" "$lastTagCommit"
  [reflection.assembly]::LoadWithPartialName("System.Version")

  $version = New-Object System.Version($versionString)
  return $version;
}

# Returns current revision by counting the number of commits to HEAD
function Get-Revision(){
   $lastTagCommit = git rev-list HEAD
   $revs  = git rev-list $lastTagCommit |  Measure-Object -Line
   return $revs.Lines
}

# Returns the next major version {major}.{minor}.{revision}
function Get-NextMajorVersion(){
    $version = Get-LastVersion;
    [reflection.assembly]::LoadWithPartialName("System.Version")
    [int] $major = $version.Major+1;
    $rev = Get-Revision
    $nextMajor = New-Object System.Version($major, 0, $rev);
    return $nextMajor;
}

# Returns the next minor version {major}.{minor}.{revision}
function Get-NextMinorVersion(){
    $version = Get-LastVersion;
    [reflection.assembly]::LoadWithPartialName("System.Version")
    [int] $minor = $version.Minor+1;
    $rev = Get-Revision
    $next = New-Object System.Version($version.Major, $minor, $rev);
    return $next;
}

# Creates a tag with the next minor version
function TagNextMinorVersion($tagMessage){
    $version = Get-NextMinorVersion;
    $tagName = "v{0}" -f "$version".Trim();
    Write-Host -NoNewline "Tagging next minor version to ";
    Write-Host -ForegroundColor DarkYellow "$tagName";
    git tag -a $tagName -m $tagMessage
}

# Creates a tag with the next major version (minor version starts again at 0)
function TagNextMajorVersion($tagMessage){
    $version = Get-NextMajorVersion;
    $tagName = "v{0}" -f "$version".Trim();
    Write-Host -NoNewline "Tagging next majo version to ";
    Write-Host -ForegroundColor DarkYellow "$tagName";
    git tag -a $tagName -m $tagMessage
}

Ответ 12

Каждая фиксация имеет уникальный хеш. Кроме того, в git нет номеров версий. Вы должны будете пометить, совершив ошибку, если вы хотите больше удобства для пользователя.

Ответ 13

Я хотел бы отметить еще один возможный подход - и это с помощью git git -notes (1), поскольку v 1.6.6 (Примечание для Self - Git) (я использую git версию 1.7.9.5).

В основном я использовал git svn для клонирования хранилища SVN с линейной историей (без стандартного макета, без ветвей, без тегов), и я хотел сравнить номера версий в клонированном репозитории git. Этот клон git по умолчанию не имеет тегов, поэтому я не могу использовать git describe. Стратегия здесь, вероятно, будет работать только для линейной истории - не уверен, как получится слияния и т.д.; но вот основная стратегия:

  • Задайте git rev-list список всех истории фиксации
    • Поскольку rev-list по умолчанию используется в "обратном хронологическом порядке", мы будем использовать его переключатель --reverse для получения списка коммитов, отсортированных по самым старым первым
  • Использовать оболочку bash для
    • увеличить переменную счетчика для каждого фиксации в качестве счетчика ревизий,
    • генерировать и добавлять временную записку git для каждой фиксации
  • Затем просмотрите журнал, используя git log с --notes, который также выведет примечание о фиксации, которое в этом случае будет "номером ревизии"
  • По завершении удаления временных заметок (NB: я не уверен, что эти заметки зафиксированы или нет, они не отображаются в git status)

Во-первых, учтите, что git имеет местоположение заметок по умолчанию, но вы также можете указать ref (erence) для заметок - который сохранит их в другом каталоге под .git; например, находясь в папке git repo, вы можете вызвать git notes get-ref, чтобы узнать, какой каталог будет:

$ git notes get-ref
refs/notes/commits
$ git notes --ref=whatever get-ref
refs/notes/whatever

Следует отметить, что если вы notes add с --ref, вы также должны впоследствии использовать эту ссылку еще раз - в противном случае вы можете получить такие ошибки, как "Нет заметки для объекта XXX...".

В этом примере я выбрал вызов ref заметок "linrev" (для линейной ревизии) - это также означает, что вряд ли процедура будет мешать уже существующим нотам. Я также использую переключатель --git-dir, поскольку, будучи новичком git, у меня возникли проблемы с пониманием этого, поэтому я хотел бы "запомнить позже" :); и я также использую --no-pager для подавления нереста less при использовании git log.

Итак, если вы находитесь в директории с подпапкой myrepo_git, которая является хранилищем git; можно было бы сделать:

### check for already existing notes:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.

### iterate through rev-list three, oldest first,
### create a cmdline adding a revision count as note to each revision

$ ix=0; for ih in $(git --git-dir=./myrepo_git/.git rev-list --reverse HEAD); do \
  TCMD="git --git-dir=./myrepo_git/.git notes --ref linrev"; \
  TCMD="$TCMD add $ih -m \"(r$((++ix)))\""; \
  echo "$TCMD"; \
  eval "$TCMD"; \
done

# git --git-dir=./myrepo_git/.git notes --ref linrev add 6886bbb7be18e63fc4be68ba41917b48f02e09d7 -m "(r1)"
# git --git-dir=./myrepo_git/.git notes --ref linrev add f34910dbeeee33a40806d29dd956062d6ab3ad97 -m "(r2)"
# ...
# git --git-dir=./myrepo_git/.git notes --ref linrev add 04051f98ece25cff67e62d13c548dacbee6c1e33 -m "(r15)"

### check status - adding notes seem to not affect it:

$ cd myrepo_git/
$ git status
# # On branch master
# nothing to commit (working directory clean)
$ cd ../

### check notes again:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# (r15)

### note is saved - now let issue a `git log` command, using a format string and notes:

$ git --git-dir=./myrepo_git/.git --no-pager log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD
# 04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)
# 77f3902: _user_: Sun Apr 21 18:29:00 2013 +0000:  >>test message 14<< (r14)
# ...
# 6886bbb: _user_: Sun Apr 21 17:11:52 2013 +0000:  >>initial test message 1<< (r1)

### test git log with range:

$ git --git-dir=./myrepo_git/.git --no-pager log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
# 04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)

### erase notes - again must iterate through rev-list

$ ix=0; for ih in $(git --git-dir=./myrepo_git/.git rev-list --reverse HEAD); do \
  TCMD="git --git-dir=./myrepo_git/.git notes --ref linrev"; \
  TCMD="$TCMD remove $ih"; \
  echo "$TCMD"; \
  eval "$TCMD"; \
done
# git --git-dir=./myrepo_git/.git notes --ref linrev remove 6886bbb7be18e63fc4be68ba41917b48f02e09d7
# Removing note for object 6886bbb7be18e63fc4be68ba41917b48f02e09d7
# git --git-dir=./myrepo_git/.git notes --ref linrev remove f34910dbeeee33a40806d29dd956062d6ab3ad97
# Removing note for object f34910dbeeee33a40806d29dd956062d6ab3ad97
# ...
# git --git-dir=./myrepo_git/.git notes --ref linrev remove 04051f98ece25cff67e62d13c548dacbee6c1e33
# Removing note for object 04051f98ece25cff67e62d13c548dacbee6c1e33

### check notes again:

$ git --git-dir=./myrepo_git/.git notes show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.
$ git --git-dir=./myrepo_git/.git notes --ref=linrev show
# error: No note found for object 04051f98ece25cff67e62d13c548dacbee6c1e33.

Итак, по крайней мере, в моем конкретном случае полностью линейной истории без ветвей номера ревизий, похоже, соответствуют этому подходу, и, кроме того, кажется, что этот подход позволит использовать git log с диапазонами ревизий, все еще получая правильные номера версий - YMMV с другим контекстом, хотя...

Надеюсь, это поможет кому-то,
Ура!

EDIT: Хорошо, здесь это немного проще, с псевдонимами git для указанных выше петель, называемых setlinrev и unsetlinrev; когда в папке репозитория git, do (Обратите внимание на отвратительное bash экранирование, см. также # 16136745 - Добавьте псевдоним git, содержащий точку с запятой):

cat >> .git/config <<"EOF"
[alias]
  setlinrev = "!bash -c 'ix=0; for ih in $(git rev-list --reverse HEAD); do \n\
      TCMD=\"git notes --ref linrev\"; \n\
      TCMD=\"$TCMD add $ih -m \\\"(r\\$((++ix)))\\\"\"; \n\
      #echo \"$TCMD\"; \n\
      eval \"$TCMD\"; \n\
    done; \n\
    echo \"Linear revision notes are set.\" '"

  unsetlinrev = "!bash -c 'ix=0; for ih in $(git rev-list --reverse HEAD); do \n\
      TCMD=\"git notes --ref linrev\"; \n\
      TCMD=\"$TCMD remove $ih\"; \n\
      #echo \"$TCMD\"; \n\
      eval \"$TCMD 2>/dev/null\"; \n\
    done; \n\
    echo \"Linear revision notes are unset.\" '"
EOF

... поэтому вы можете просто вызвать git setlinrev, прежде чем пытаться сделать журнал с использованием заметок линейной ревизии; и git unsetlinrev, чтобы удалить эти заметки, когда вы закончите; пример из каталога git repo:

$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 <<

$ git setlinrev
Linear revision notes are set.
$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 << (r15)
$ git unsetlinrev
Linear revision notes are unset.

$ git log --notes=linrev --format=format:"%h: %an: %ad:  >>%s<< %N" HEAD^..HEAD
04051f9: _user_: Sun Apr 21 18:29:02 2013 +0000:  >>test message 15 <<

Время, затрачиваемое оболочкой на выполнение этих псевдонимов, будет зависеть от размера истории хранилища.

Ответ 14

Для людей, у которых есть Ant процесс сборки, вы можете создать номер версии для проекта на git с этой целью

<target name="generate-version">

    <exec executable="git" outputproperty="version.revisions">
        <arg value="log"/>
        <arg value="--oneline"/>
    </exec>

    <resourcecount property="version.revision" count="0" when="eq">
        <tokens>
            <concat>
                <filterchain>
                    <tokenfilter>
                        <stringtokenizer delims="\r" />
                    </tokenfilter>
                </filterchain>
            <propertyresource name="version.revisions" />
            </concat>
        </tokens>
    </resourcecount>
    <echo>Revision : ${version.revision}</echo>

    <exec executable="git" outputproperty="version.hash">
        <arg value="rev-parse"/>
        <arg value="--short"/>
        <arg value="HEAD"/>
    </exec>
    <echo>Hash : ${version.hash}</echo>


    <exec executable="git" outputproperty="version.branch">
        <arg value="rev-parse"/>
        <arg value="--abbrev-ref"/>
        <arg value="HEAD"/>
    </exec>
    <echo>Branch : ${version.branch}</echo>

    <exec executable="git" outputproperty="version.diff">
        <arg value="diff"/>
    </exec>

    <condition property="version.dirty" value="" else="-dirty">
        <equals arg1="${version.diff}" arg2=""/>
    </condition>

    <tstamp>
        <format property="version.date" pattern="yyyy-mm-dd.HH:mm:ss" locale="en,US"/>
    </tstamp>
    <echo>Date : ${version.date}</echo>

    <property name="version" value="${version.revision}.${version.hash}.${version.branch}${version.dirty}.${version.date}" />

    <echo>Version : ${version}</echo>

    <echo file="version.properties" append="false">version = ${version}</echo>

</target>

Результат выглядит следующим образом:

generate-version:
    [echo] Generate version
    [echo] Revision : 47
    [echo] Hash : 2af0b99
    [echo] Branch : master
    [echo] Date : 2015-04-20.15:04:03
    [echo] Version : 47.2af0b99.master-dirty.2015-04-20.15:04:03

Грязный флаг здесь, когда у вас есть файл (ы), который не был зафиксирован при создании номера версии. Поскольку обычно, когда вы создаете/упаковываете приложение, каждая модификация кода должна находиться в репозитории.

Ответ 15

Наряду с идентификатором SHA-1 фиксации помогли бы время и время сервера.

Что-то вроде этого:

совершение произошло в 11:30:25 на 19 августа 2013 года. 6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025

Ответ 16

В руководстве Git теги являются блестящим ответом на эту проблему:

Создание аннотированного тега в Git прост. Самый простой способ - укажите -a, когда вы запустите команду тега:

$ git tag -a v1.4 -m 'my version 1.4'

$ git tag
v0.1
v1.3
v1.4

Отъезд 2.6 Git Основы - Отметка

Ответ 17

Мы используем эту команду для получения версии и ревизии из git:

git describe --tags --exact-match 2> /dev/null || git describe --always

Возвращается

  • зафиксировать хэш как ревизию, когда теги не используются (например, gcc7b71f)
  • имя тега как версия в теге (например, v2.1.0, используется для выпусков)
  • имя тега, номер ревизии с момента последнего тега и фиксация хэша после тега (например, v5.3.0-88-gcc7b71f)

Ответ 18

TortoiseGit полагает, что первые 7 цифр SHA-1 - это ревизия. Когда вы просматриваете журнал в файле, диалог отображается внизу:

Отображение N ревизий (версий), от версии ABCDEF1 до версии FEFCBA1

Это правильный ответ, если TortoiseGit сочтет это так?

Ответ 19

После длительного изучения в онлайн-хранилищах я обнаружил, что логически нет разницы между номером ревизии и номером фиксации в Git.

Ответ 20

Событие после сборки для Visual Studio

echo  >RevisionNumber.cs static class Git { public static int RevisionNumber =
git  >>RevisionNumber.cs rev-list --count HEAD
echo >>RevisionNumber.cs ; }

Ответ 21

Подумайте об использовании

git-rev-label

Предоставляет информацию о ревизии Git-репозитория в формате, подобном master-c73-gabc6bec. Может заполнить строку шаблона или файл переменными окружения и информацией из Git. Полезно для предоставления информации о версии программы: ветка, тег, хеш коммита, количество коммитов, грязный статус, дата и время. Одна из самых полезных вещей - это подсчет фиксирует, не принимая во внимание объединенные ветки - только первый родитель.