Помещать префикс? <число пересмотра> к кодам Git/SVN

"в вашем репозитории"? в вашем репозитории напрямую ?
Это будет называться " расширение ключевого слова ", и это не рекомендуется (как обсуждается в этом вопросе SO )

Внесение метаданных (номер версии) в данные, хранящиеся в репозитории может привести к проблемам слияния .

То, что вы видите на страницах SO, является результатом процесса развертывания, который берет метаданные из SVN (ревизия) и помещает их в сгенерированные страницы HTML.

GitFaq также не рекомендует его.
Эквивалент номера версии SVN, интегрированной в файлы, развернутые на сервере, будет использовать git description , чтобы получить своего рода «счетчик фиксации», отображаемый на этапе развертывания.

Но запись это непосредственно в репозитории будет означать расширение ключевых слов, и ключевое слово un расширение.

Чтобы проиллюстрировать это, давайте проверим, что сказал Линус во время первоначального обсуждения этой темы (Апрель 2007 г.):

Добавить расширение не просто «сложнее». Практически невозможно обойтись каким-либо спектаклем.
Подумайте: « git checkout newbranch ».
И подумайте, что мы делаем с файлами (и целыми подкаталогами!), Которые даже не изменились. И, наконец, подумайте, насколько важна эта оптимизация в SCM, подобном git, который поддерживает ветки.

[] фундаментальные проблемы, связанные с расширением ключевых слов (т.е. переключение ветвей в принципе невозможно обойтись без проверки каждого_сингла_файла с установленным атрибутом «ключевое слово». Есть и другие).

выполнить тривиально (на самом деле это то же самое, что и перевод "CRLF-> LF": технически это тоже просто "нерасширение"). И это должно работать.

То, как это делает расширение, также нарушает "git diff", поскольку в основном оно всегда заставляет diff игнорировать ключевые слова. Другими словами, когда вы выполняете

git diff A..B

и отправляете разницу кому-то другому, они вообще никогда не увидят никаких ключевых слов!

Это, очевидно, соответствует моему требованию, чтобы разница была пустой, если A и B совпадают, так что вы должны ожидать, что я буду счастлив.
Но я не доволен, потому что, если другой человек также использует git, ОН НЕ МОЖЕТ ДАЖЕ ПРИМЕНИТЬ РАЗНИЦА!
Даже если он находится на отметке «А» и, таким образом, получает разницу, которая должна применяться точно , он получит отклонения, если были другие изменения вокруг нерасширенного ключевого слова (что он будет конечно, расширились в его рабочем дереве!)

Видите? Ключевые слова просто не могут работать. Они сломаны. Либо вы можете игнорировать их (и не показывать их в diffs), и в этом случае diff не работает, либо вы не можете игнорировать их (и показывать их в diffs), и в этом случае diff также нарушен, просто по-другому.

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

If this version number is generated by some server script: PHP, Perl, ASP.NET, Ruby on Rails (VonC explained why keyword expansion is a bad idea, i.e. why making Git and not web server update such information is a bad idea), then it is simply matter of running git describe in this script.

Another solution is to make deployment (build) system, which copies files from version control system to web server, embed this data. For example gitweb, git web interface for Git written in Perl, has

our $version = "++GIT_VERSION++";

replaced by build system (make gitweb/gitweb.cgi) by result of running GIT-VERSION-GEN. This means for example that running gitweb shows in "generator" meta header for example:

<meta name="generator" content="gitweb/1.6.4.rc0.22.gfc1cf.dirty git/1.6.3.2.317.g2dd3f"/>

Игнорируя слово «эффективно» в вашем вопросе, вы должны найти «драйвер фильтра». Простое пятно для вставки ревизии и чистое пятно для его удаления должно делать то, что вы (думаете) хотите.