Я прочитал кучу вопросов о простых инструментах управления исходным кодом, и Git показался мне разумным выбором. Он у меня есть и работает, и пока он работает хорошо. Один из аспектов, который мне нравится в CVS, - это автоматическое увеличение номера версии.
Я понимаю, что в распределенном репозитории это не имеет смысла, но как разработчик я хочу / нуждаюсь в чем-то подобном. Позвольте мне объяснить почему:
Я использую Emacs. Периодически я просматриваю и ищу новые версии исходных файлов Lisp для сторонних пакетов. Допустим, у меня есть файл foo.el, который, согласно заголовку, имеет версию 1.3; если я посмотрю на последнюю версию и увижу, что это 1.143 или 2.6 или что-то еще, я знаю, что сильно отстаю.
Если вместо этого я увижу пару 40-символьных хэшей, я не узнаю, какой из них будет позже, и не пойму, сколько позже. Я бы абсолютно ненавидел, если бы мне пришлось вручную проверять журналы изменений, чтобы понять, насколько я устарел.
Как разработчик, я хочу выразить эту любезность, как я это вижу, людям, которые используют мои результаты (и, возможно, я обманываю себя, что кто-то есть, но давайте оставим это на мгновение). Я не хочу, чтобы мне приходилось каждый раз самому увеличивать проклятое число, или временную метку, или что-то в этом роде. Это настоящая PITA, и я знаю это по опыту.
Итак, какие у меня есть альтернативы? Если я не могу получить эквивалент $ Id: $, как еще я могу предоставить то, что ищу?
Я должен упомянуть, что я ожидаю, что у конечного пользователя НЕ будет установлен Git, и даже если он установит, у него не будет локального репозитория (действительно, я не ожидаю, что он будет доступен таким образом).
источник
filter-branch
или что-то в этом роде.git describe
команду непосредственно перед сборкой, сохранить вывод в файле заголовка или иным образом встроить значение в свой код.К настоящему времени в Git есть поддержка $ Id: $. Чтобы включить его для файла README, вы должны поместить "README identity " в .gitattributes . Поддерживаются подстановочные знаки в именах файлов. Подробнее см. Man gitattributes .
источник
$Id$
упомянутому. Вы получаете именно то, что хранится отдельно. В любом случае версия принадлежит полному набору файлов, составляющих коммит, а не одному файлу в частности (эта идея - пережиток времен RCS, или, возможно, SCCS здесь виноват ... Поскольку CVS - это просто прославил интерфейс для RCS, а SVN пытается быть похожим на CVS, он застрял.).Это не необоснованный запрос OP.
Мой вариант использования:
/usr/local/bin
когда будут готовы.Я использую три отдельные машины с одним и тем же репозиторием Git. Было бы неплохо узнать, в какой «версии» файла я сейчас
/usr/local/bin
без необходимости вручную выполнять «diff -u <repo version> <version in / usr / local / bin>».Тем из вас, кто настроен отрицательно, помните, что есть и другие варианты использования. Не все используют Git для совместной работы с файлами в репозитории Git, которые являются их «окончательным» местоположением.
Во всяком случае, я сделал это так, чтобы создать файл атрибутов в репозитории следующим образом:
Затем поместите где-нибудь в файле $ Id $ (я люблю ставить его после shebang).
Коммит. Обратите внимание, что это не делает расширение автоматически, как я ожидал. Вам нужно пересобрать файл, например,
И тогда вы увидите расширение, например:
Полезная информация содержится в разделе Как включить строку идентификатора для репозитория Git? ,
источник
git co
делать? Я получил сообщение об ошибке "git: 'co' is not a git command. See 'git --help'.
" Должно бытьgit checkout
?Не уверен, что это когда-нибудь будет в Git. Чтобы процитировать Линус :
Тем не менее, довольно легко проверить журнал - если вы отслеживаете стабильную ветку foo.el, вы можете увидеть, какие новые коммиты есть в журнале стабильной ветки, которых нет в вашей локальной копии. Если вы хотите имитировать внутренний номер версии CVS, вы можете сравнить отметку времени последней фиксации.
Edit: для этого нужно писать или использовать чужие скрипты, конечно, не делать это вручную.
источник
$Id$
viaident
, как упоминалось в другом ответе здесь, показывая, что даже сам git не является заложником мнения Линуса.Как я уже писал ранее :
источник
У меня такая же проблема. Мне нужна была версия, которая была бы проще, чем хеш-строка, и была доступна для людей, использующих инструмент, без необходимости подключаться к репозиторию.
Я сделал это с помощью ловушки предварительной фиксации Git и изменил свой скрипт, чтобы он мог автоматически обновляться.
Я основываю версию на количестве сделанных коммитов. Это небольшое состояние гонки, потому что два человека могут фиксировать одновременно, и оба думают, что фиксируют один и тот же номер версии, но у нас не так много разработчиков в этом проекте.
В качестве примера у меня есть сценарий, который я проверяю на Ruby, и я добавляю к нему этот код - это довольно простой код, поэтому его легко переносить на разные языки, если вы проверяете что-то на другом языке (хотя, очевидно, это не будет легко работать с неработающими отметками, такими как текстовые файлы). Я добавил:
А затем я добавляю в сценарий параметр командной строки (-updateVersion), поэтому, если я назову его как «tool -updateVersion», он просто вызовет updateVersion для инструмента, который изменяет значение «MYVERSION» в себе, а затем завершает работу (вы могли пусть он также обновит другие файлы, если они открыты, если хотите).
После настройки я перехожу к заголовку Git и создаю исполняемый однострочный сценарий bash в
.git/hooks/pre-commit
.Скрипт просто переходит в заголовок каталога Git и вызывает мой скрипт с
-updateVersion
.Каждый раз, когда я проверяю, запускается сценарий предварительной фиксации, который запускает мой сценарий с -updateVersion, а затем переменная MYVERSION обновляется в зависимости от того, какое количество фиксаций будет. Магия!
источник
git updateVersion
? Приложите, пожалуйста, несколько примеров того, как это называется.Если для вас важно наличие $ Keywords $, то, может быть, вы могли бы попробовать вместо этого взглянуть на Mercurial ? У него есть расширение hgkeyword, которое реализует то, что вы хотите. В любом случае Mercurial интересен как DVCS.
источник
Что-то, что делается с репозиториями Git, - это использовать
tag
объект. Его можно использовать для пометки фиксации строкой любого типа и для отметки версий. Вы можете увидеть эти теги в репозитории с помощьюgit tag
команды, которая возвращает все теги.Проверить тег легко. Например, если есть тег,
v1.1
вы можете проверить этот тег в ветке следующим образом:Поскольку это объект верхнего уровня, вы увидите всю историю этого коммита, а также сможете запускать сравнения, вносить изменения и объединять.
Не только это, но и тег сохраняется, даже если ветка, в которой он находился, была удалена без повторного объединения с основной строкой.
источник
export-subst
функцииgitattributes(5)
. Это, конечно, требует использованияgit archive
для создания выпусков, и только в итоговом файле tar будут видны изменения подстановки.Если я правильно понимаю, по сути, вы хотите знать, сколько коммитов произошло с данным файлом с момента последнего обновления.
Сначала получите изменения в удаленном источнике, но не объединяйте их в свою
master
ветку:Затем получите журнал изменений, которые произошли в данном файле между вашей
master
веткой и удаленным компьютеромorigin/master
.Это дает вам сообщения журнала всех коммитов, которые произошли в удаленном репозитории с момента последнего слияния
origin/master
с вашимmaster
.Если вы просто хотите подсчитать количество изменений, отправьте его по конвейеру
wc
. Скажем так:источник
Если вы просто хотите, чтобы люди понимали, насколько они устарели, Git может сообщить им об этом несколькими довольно простыми способами. Например, они сравнивают даты последней фиксации в своей стволе и вашей стволе. Они могут использовать их,
git cherry
чтобы узнать, сколько коммитов произошло в вашем стволе, чего нет в их.Если это все, что вам нужно, я бы поискал способ предоставить его без номера версии.
Кроме того, я бы не стал проявлять любезность к кому-либо, если вы не уверены, что они этого хотят. :)
источник
Чтобы применить расширение ко всем файлам во всех подкаталогах в репозитории, добавьте
.gitattributes
файл в каталог верхнего уровня в репозитории (то есть туда, куда вы обычно помещаете.gitignore
файл), содержащий:Чтобы увидеть это в действии, вам нужно сначала выполнить эффективную проверку файла (ов), например удалить или отредактировать их любым способом. Затем восстановите их с помощью:
И вы должны увидеть
$Id$
замену на что-то вроде:Из
man gitattributes
:Этот идентификатор будет изменяться каждый раз, когда фиксируется новая версия файла.
источник
Идентификаторы RCS удобны для однофайловых проектов, но для любых других $ Id $ ничего не говорит о проекте (если только вы не выполняете принудительные фиктивные проверки для файла фиктивной версии).
Тем не менее, может быть интересно, как получить эквиваленты $ Author $, $ Date $, $ Revision $, $ RCSfile $ и т. Д. На уровне файла или на уровне фиксации (как разместить их там, где находятся некоторые ключевые слова, это другое вопрос). У меня нет ответа на эти вопросы, но я вижу необходимость их обновления, особенно когда файлы (теперь в Git) происходят из RCS-совместимых систем (CVS).
Такие ключевые слова могут быть интересны, если исходники распространяются отдельно от любого репозитория Git (я тоже этим занимаюсь). Мое решение таково:
У каждого проекта есть собственный каталог, а в корне проекта у меня есть текстовый файл с именем
.version
содержимое которого описывает текущую версию (имя, которое будет использоваться при экспорте источников).Во время работы над следующим выпуском сценарий извлекает этот
.version
номер, некоторый дескриптор версии Git (напримерgit describe
) и монотонный номер сборки.build
(плюс хост и дату) в автоматически сгенерированный исходный файл, связанный с окончательной программой, чтобы вы могли найти из какого источника и когда он был построен.Я разрабатываю новые функции в отдельных ветках, и первое, что я делаю, это добавляю
n
(для «следующего») в.version
строку (несколько ветвей, происходящих из одного корня, будут использовать один и тот же временный.version
номер). Перед выпуском я решаю, какие ветки объединить (надеюсь, все они одинаковые.version
). Перед фиксацией слияния я обновляюсь.version
до следующего номера (основное или незначительное обновление, в зависимости от объединенных функций).источник
Если вы хотите, чтобы информация о коммитах git была доступна в вашем коде, вам нужно выполнить предварительную сборку, чтобы получить ее. В bash для C / C ++ это может выглядеть примерно так:
prebuild.sh
с
version.h
видом:Затем, где бы вам это ни понадобилось, в коде
#include "version.h"
и справочникеgit_tag
или поgit_commit
мере необходимости.И у вас
Makefile
может быть что-то вроде этого:Это дает следующие преимущества:
Эта реализация
prepublish.sh
имеет следующие недостатки:git_tag
/git_commit
не изменился.git describe --tags --always --dirty
чтобы поймать этот вариант использования.Любитель,
prebuild.sh
который мог бы избежать этих проблем, оставлен в качестве упражнения для читателя.источник
Я согласен с теми, кто считает, что замена токена относится к инструментам сборки, а не к инструментам контроля версий.
У вас должен быть какой-то автоматический инструмент выпуска, чтобы установить идентификаторы версий в ваших источниках во время маркировки выпуска.
источник
Теперь Git может автоматически редактировать имена тегов и другую связанную информацию непосредственно в файлах с помощью
export-subst
функцииgitattributes(5)
. Это, конечно, требует использованияgit archive
для создания выпусков, и только в итоговом файле tar будут видны изменения подстановки.Например, в
.gitattributes
файле поместите следующую строку:Затем в исходных файлах вы можете добавить такую строку:
И он будет расширяться, чтобы выглядеть так в выпуске, созданном, например, следующим образом
git archive v1.2.0.90
:источник
Поскольку вы используете Emacs, возможно, вам повезет :)
Я столкнулся с этим вопросом случайно, а также случайно, что несколько дней назад я получил от Lively пакет Emacs, который позволяет иметь живые части Emacs Lisp в вашем документе. Я не пробовал, если честно, но это пришло мне в голову при чтении этого.
источник
Я также пришел из SCCS, RCS и CVS (
%W% %G% %U%
).У меня была похожая проблема. Я хотел знать, какая версия кода была в любой системе, в которой он запущен. Система может быть подключена или не подключена к какой-либо сети. В системе может быть установлен или не установлен Git. В системе может быть установлен или не установлен репозиторий GitHub.
Мне нужно было одно и то же решение для нескольких типов кода (.sh, .go, .yml, .xml и т. Д.). Я хотел, чтобы любой человек, не знакомый с Git или GitHub, мог ответить на вопрос «Какая у вас версия?»
Итак, я написал то, что я называю оболочкой для нескольких команд Git. Я использую его, чтобы пометить файл номером версии и некоторой информацией. Это решает мою задачу. Это может вам помочь.
https://github.com/BradleyA/markit
источник
Чтобы решить эту проблему для себя, я создал небольшой «хак» в качестве ловушки после фиксации:
Более подробно описано в этом посте в моем блоге .
источник