Git ключевое слово-расширение или альтернатива - PullRequest
Новая
       18

Git ключевое слово-расширение или альтернатива

1 голос
/ 15 марта 2012

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

У меня есть основное приложение, для которого я использую git в качестве VCS. Части этого основного приложения (определенный набор XML-файлов) используются утилитой, для которой я также использую git (отдельное хранилище).

Теперь основное приложение и утилита имеют разные циклы выпуска, и всякий раз, когда я выпускаю новую версию утилиты, я копирую самый последний набор XML-файлов из основного приложения. Внутри утилиты этот набор XML-файлов является не версионным контентом в git, поэтому он даже не зарегистрирован в репо.

На данный момент, когда я смотрю на разные выпуски этой утилиты (которая управляется git и имеет помеченные выпуски), у меня нет возможности узнать, какая "версия" (лучше: commit хэш) набор содержащихся XML-файлов имеет в виду.

Поэтому я подумал: если я смогу получить последний SHA-коммит в этих XML-файлах (как комментарий), я всегда буду знать, к какому набору XML-файлов относится определенная версия моей утилиты. Есть ли что-то не так в этом подходе или это путь? Если да, как мне вставить последний коммит-SHA в мои XML-файлы? (Я читал, что $ Id: $ не будет принимать коммит-SHA, но какой-нибудь "blob" -SHA?)

Ответы [ 4 ]

5 голосов
/ 16 марта 2012

Два варианта

Использование подмодулей

Вы можете создать основное приложение в виде репо + подмодуль для XML-данных. Поскольку вы не можете использовать часть git-repo в качестве подмодуля в другом репо, только полное репо (Git-boys, FIXME), вы должны заново создать утилиту repo как " супермодуль "и разделение репо на две части - утилита + XML-данные

Основной репо также становится «супермодулем» и будет 1) включать основное приложение и 2) XML-данные для приложения

Поскольку Git поддерживает строгую связь между наборами изменений в основном репо и подмодуле для всех и любого базового идентификатора набора изменений (Git-boys, FIXME), вы можете знать только хэш основного приложения и связываться с этим снимком набора изменений XML-данных.

Чистящие фильтры

Сохраняя репо как полностью независимые, вы можете добавлять данные отслеживания в XML-файлы. Правильный способ добавить любое произвольное ключевое слово в данные, контролируемые Git, - Фильтры очистки от грязи (см. Раздел «Расширение ключевого слова» и пример расширения $ Date $ ключевого слова)

2 голосов
/ 15 марта 2012

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

Во время сборки вы можете получить информацию о версии непосредственно из git с помощью git describe или git rev-parse HEAD (см. Вставка текущего идентификатора коммита git в веб-приложение Java).)

2 голосов
/ 15 марта 2012

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

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

Поскольку ваш файл не отслеживается, изменения в нем не изменят значение хеш-функции, поэтому приведенное выше не является проблемой. Существует несколько способов получения текущего хэша SHA1, самый простой из которых, вероятно, заключается в просмотре .git/refs/heads/master. Этот файл является указателем для ветви master и содержит хэш фиксации HEAD в этой ветви. Конечно, вы можете изменить /master на любую другую ветку, если хотите.

0 голосов
/ 16 марта 2012

Хорошо, ребята, основываясь на ваших комментариях, вот что я сделал:

  1. Вставьте заполнители в мои XML-файлы: <!-- @GIT_VERSION@ -->
  2. Получите информацию о версии git для ant.Обратите внимание, что это Windows:
  3. Пусть муравей вставит эту информацию в мои XML-файлы, копируя их.

Код: 

<target name="getGitDetails">
    <exec executable="cmd" outputproperty="git.revision">
         <arg value="/c" />
         <arg value="git.cmd --git-dir=<path-to-repo> describe --long --dirty --always" />
    </exec>
     <exec executable="cmd" outputproperty="git.currentBranchRef">
         <arg value="/c" />
         <arg value="git.cmd --git-dir=<path-to-repo> describe --all" />
     </exec>
 </target>

 <target name="build" depends="getGitDetails">
     <copy todir="<dest-dir>">  
         <filterset>
             <filter token="GIT_VERSION" value="${git.currentBranchRef} ${git.revision}" />
         </filterset>
     </copy>
 </target>

Спасибо заваша помощь!

См. также:

Как найти последний хэш git commit из скрипта сборки ant

Получение версии сборки приложенияиз `git description` - как получить относительно простую строку?

...