it-roy-ru.com

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

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

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

220
Radek

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

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

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

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

Начните с релиза: 3.0.8. Затем, после этого релиза, сделайте это:

git branch bugfixes308

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

git checkout bugfixes308

Теперь внесите любые исправления ошибок, которые вы хотите.

git commit -a

Зафиксируйте их и переключитесь обратно в главную ветку:

git checkout master

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

git merge bugfixes308

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

138
makdad

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

$ git rev-list --count HEAD
68
149
max

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

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

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

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

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

95
Greg Hewgill

Остальные постеры правы, «номер ревизии» отсутствует.

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

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

Показать "текущую версию" 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 тогда напечатает hash для "revision" :)

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

67
OderWat

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

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

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

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

Теперь, поскольку у нас есть DAG (направленный ациклический граф) ревизий, и они составляют текущее дерево, нам нужны некоторые инструменты для решения вашей проблемы: Как мы различаем разные версии. Во-первых, вы можете опустить часть хэша, если данный префикс 1516bd скажем, однозначно идентифицирует ваш коммит. Но это тоже довольно надумано. Вместо этого, хитрость заключается в использовании тегов и/или ветвей. Тег или ветка похожи на «желтую заметку», которую вы прикрепляете к определенному SHA1-идентификатору коммита. По сути, теги должны быть неподвижными, в то время как ветвь будет двигаться, когда в ее HEAD будут сделаны новые коммиты. Существуют способы ссылки на коммит вокруг тега или ветви, см. Справочную страницу git-rev-parse.

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

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

25
I GIVE CRAP ANSWERS

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

<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)
17
Sebastien Varrette

Функция 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
siznax

SHA1 хеш коммита является эквивалентом номера ревизии Subversion.

8
Richard Fearn

Это то, что я сделал в своем 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
6
Ralph Williamson

Я написал несколько утилит 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
}
5
toeb

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

4
Jim Belton

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

4
Core Xii

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

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

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

Во-первых, давайте отметим, что git имеет расположение заметок по умолчанию - но вы также можете указать ref (erence) для заметок - который будет хранить их в другом каталоге под .git; например, находясь в папке репозитория git, вы можете вызвать 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's 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 с другим контекстом, хотя ...

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


Правка: Хорошо, здесь это немного проще, с псевдонимами git для вышеуказанных циклов, называемых setlinrev и unsetlinrev; когда в вашей папке Git репозитория, сделайте (Обратите внимание на неприятную 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 <<

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

3
sdaau

Для людей, у которых есть процесс Ant build, вы можете сгенерировать номер версии для проекта на 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

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

2
Fredo

Из руководства по Git теги - блестящий ответ на этот вопрос:

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

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

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

Проверить 2.6 Основы Git - Пометка

1
DJ Far

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

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

фиксация произошла в 11:30:25 19 августа 2013 г. и будет отображаться как 6886bbb7be18e63fc4be68ba41917b48f02e09d7_19aug2013_113025

1
Manoranjan Sahu

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

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

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

0
Judith Francisca