Git отслеживает версии? - PullRequest
5 голосов
/ 02 марта 2010

Я новичок в Git с опытом работы в UNIX SCCS и Microsoft Visual SourceSafe.

В SCCS каждый файл имеет версию (I%), которая состоит из версии (% R), уровня (L%), ветви (% B) и последовательности (S%). % I равен R%.% L.B%.% S, хорошо? Они называются ключевыми словами ID.

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

printf («Версия s \ n», «% I»);

... станет,

printf («Версия% s \ n», «1.4.6.2»);

Который напечатает,

Версия 1.4.6.2

SCCS отслеживает версии файлов по отдельности и увеличивает их каждый раз, когда они регистрируются.

Есть что-нибудь похожее на это в Git?

Ответы [ 2 ]

5 голосов
/ 02 марта 2010

Как обсуждалось в вопросе SO " Чтобы поставить префикс? Для кодов Git / Svn ", Git не имеет расширения ключевого слова RCS.

Ближайшая команда Git будет git describe, чтобы иметь какую-то ссылку на коммит.

Но обычно не стоит смешивать метаданные (т. Е. Данные "id версии" о data "файл") с данными ( файлы).
Если вы действительно нуждаетесь в такого рода информации, более практичным является отдельный специальный файл со списком вашего другого обычного файла с соответствующим идентификатором версии.

Даже ClearCase, который имеет схожие с SCS понятия в отношении ветки и последовательности для каждого файла, не имеет встроенных номеров версий: См. Номера встроенных версий - Хорошо или Зло? .

4 голосов
/ 02 марта 2010

Вы можете генерировать уникальные имена тегов, используя git-description .

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

Пример того, как определить номер версии программного обеспечения с помощью «git description» ( здесь ):

01  git commit -m'Commit One.'
02  git tag -a -m'Tag One.' 1.2.3
03  git describe    # => 1.2.3
04  git commit -m'Commit Two.'
05  git describe    # => 1.2.3-1-gaac161d
06  git commit -m'Commit Three.'
07  git describe    # => 1.2.3-2-g462715d
08  git tag -a -m'Tag Two.' 2.0.0
09  git describe    # => 2.0.0
...