Моделирование глобального числа пересмотра с мерзавцем

Как я пошел бы о моделировании глобального числа пересмотра увеличения для каждой фиксации в мерзавце основная строка?

Так, после того, как я фиксирую, я хотел бы, чтобы сценарий работал, увеличивает число где-нибудь.

Это позволит мне говорить моим клиентам легко, что X функций были зафиксированы в пересмотре мерзавца XYZ.

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

16
задан Sam Saffron 29 November 2009 в 22:22
поделиться

4 ответа

git describe дает описание версии, подобное следующему: v2.0-64-g835c907 . Часть v2.0 - это имя последнего аннотированного тега, предшествующего фиксации, 64 - количество коммитов после этого, а 835c907 - сокращенное коммит Я бы. В основном он используется для точной и удобной (хотя и технической) идентификации любой ревизии.

Примечание : Для этого вам понадобится как минимум один аннотированный тег. Чтобы создать его для версии v2.0, запустите - git tag -a v2.0 , если у вас нет аннотированных тегов, эта команда завершится ошибкой, если не указан резервный аргумент, например - теги или - всегда .

27
ответ дан 30 November 2019 в 16:09
поделиться

В git можно смоделировать номер ревизии, однако важно знать, что это не идеальное совпадение, и отследить его не так просто. Лично я использую его, чтобы сделать более простые номера версий для веб-приложений, потому что я единственный разработчик. Я использую следующую функцию в моем .bashrc , чтобы получить номер версии, который затем использую для примечаний к выпуску (однако, если вы еще этого не сделали, я настоятельно рекомендую пометить выпуск - тогда этот номер предназначен только для пользователей ). Если ограничения хорошо известны, это дает гораздо более удобный номер версии.

function rgit() {
    git rev-list --abbrev-commit HEAD | wc -l | awk '{print $1}'
}
9
ответ дан 30 November 2019 в 16:09
поделиться

Я думаю, вы сбиваете с толку ревизию номера с номерами выпусков.

Subversion использует номера ревизий, потому что может: это централизованный репозиторий. Git, конечно, имеет хэши SHA-1, а не номера ревизий, потому что у него нет центрального репозитория (но вы это знаете).

Этот номер ревизии (а хеш технически представляет собой 160-битное число, он просто не последовательный) не должен беспокоить ваших клиентов. Их должен интересовать номер версии. Это когда вы упаковываете исходный код и говорите: «Это версия 2.3.4»,

6
ответ дан 30 November 2019 в 16:09
поделиться

Я (не зная о git describe ) использовал следующий скрипт:

#!/bin/bash

FULL_BRANCH=`git branch | grep '*'`
BRANCH_NAME=${FULL_BRANCH:2}
REV=`git rev-parse --short HEAD`

$COMMIT_NAME = $BRANCH_NAME-$REV

Это дает вам имя, которое содержит имя текущей ветки, за которым следует короткое идентификатор фиксации. Например: master-c03f862 .

Достаточно делать то, что вам нужно, но, возможно, git describe - правильный путь.

1
ответ дан 30 November 2019 в 16:09
поделиться
Другие вопросы по тегам:

Похожие вопросы: