Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
А как потом можно найти коммит, имея номер тега и количество коммитов после этого тэга?
Скорее всего никак (или очень затруднительно). История в git — однонаправленный граф, и просто идти «вперёд» по истории не получится.
А зачем? Если так нужно для последующей возможной ловли багов, то проще хранить сразу хэш коммита для этой цели (и показывать его где-нибудь в «О программе»).
А зачем? Если так нужно для последующей возможной ловли багов, то проще хранить сразу хэш коммита для этой цели (и показывать его где-нибудь в «О программе»).
Да, для багов и тестирования. Хэш храню и показываю, но числовая версия для пользователей проще и человечнее, чем хэш :)
Вообще, весь список коммитов после тэга можно посмотреть через git log v0.8..master (и git describe именно так высчитывает количество коммитов), но я не уверен, что там не возникнет какая-нибудь неопределенность с порядком коммитов из-за merge команд.
Вообще, весь список коммитов после тэга можно посмотреть через git log v0.8..master (и git describe именно так высчитывает количество коммитов), но я не уверен, что там не возникнет какая-нибудь неопределенность с порядком коммитов из-за merge команд.
В выводе git describe есть первые несколько символов идентификатора коммита. Собственно, этого будет достаточно.
Идея достаточно хорошая. И всё же, её можно немного расширить для масштабируемости следующим образом:
1. Делим всю работу на бранчи master/develop/feature/hotfix и далее по вкусу, как описано в куче трудов.
2. Если вы привязываетесь к количеству коммитов, то логичным будет всю работу делать в feature-бранчах, и по окончанию этой работы делать
Результат: это даст увеличение количества коммитов в develop-ветке ровно на один, что будет соотвествовать единице добавленного функционала. То есть в dev-бранче +1 версия = +1 реализованный функционал. Удобно.
В feature-бранче же версия, посчитанная вашим образом, имеет конечный смысл для разработчика. И поэтому даст свободу по количеству коммитов в feature-бранче. Я например часто коммичу, тк стараюсь делать это достаточно атомарно.
Но, к сожалению, неизбежно возникает конфликт версий между dev-веткой и feature-веткой, тк версии считаются одинаково. Поэтому, я бы предложил форматировать версию для feature-ветки как-нибудь так:
Схема:
Имхо, так лучше.
1. Делим всю работу на бранчи master/develop/feature/hotfix и далее по вкусу, как описано в куче трудов.
2. Если вы привязываетесь к количеству коммитов, то логичным будет всю работу делать в feature-бранчах, и по окончанию этой работы делать
git merge --no-ff в develop-ветку. Результат: это даст увеличение количества коммитов в develop-ветке ровно на один, что будет соотвествовать единице добавленного функционала. То есть в dev-бранче +1 версия = +1 реализованный функционал. Удобно.
В feature-бранче же версия, посчитанная вашим образом, имеет конечный смысл для разработчика. И поэтому даст свободу по количеству коммитов в feature-бранче. Я например часто коммичу, тк стараюсь делать это достаточно атомарно.
Но, к сожалению, неизбежно возникает конфликт версий между dev-веткой и feature-веткой, тк версии считаются одинаково. Поэтому, я бы предложил форматировать версию для feature-ветки как-нибудь так:
Версия 0.8.2-<имя feature-ветки>-<количество коммитов в ней>, где 0.8.2 — версия из dev, от которой пошла feature-ветка. Конечный результат: 0.8.2-new_ui-9Схема:
Версия 0.8.2|...........-> 0.8.3
Ветка dev -----------------------
Ветка new-ui \........./
Имхо, так лучше.
Не сработает:
И…
Упс, а посчитались-то все коммиты.
После merge'а git уже не может сказать, какой же ветке принадлежал коммит, поэтому считает все. И я не знаю, как git describe'у сказать «а в мёрдж-коммитах следуй по первой ссылке на родителя».
mkdir tmp && cd tmp
git init .
# Корневой коммит, он же v1.0
touch a && git add a && git commit -m "0"
git tag -a -m "version 1.0" v1.0
# Переключаемся в ветку devделаем работу в ней
git checkout -b dev
touch b && git add b && git commit -m "1"
# Обратно в мастер
git checkout master
touch c && git add c && git commit -m "2"
# И снова в dev
git checkout dev
touch d && git add d && git commit -m "3"
# А теперь merge
git checkout master
git merge --no-ff dev
# И что в итоге?
git describe
И…
v1.0-4-geafc8e0Упс, а посчитались-то все коммиты.
После merge'а git уже не может сказать, какой же ветке принадлежал коммит, поэтому считает все. И я не знаю, как git describe'у сказать «а в мёрдж-коммитах следуй по первой ссылке на родителя».
а кто и зачем собрался держать код вне репозитория?
Например, в src-пакетах всех ведущих дистрибутивов Linux.
Еще полезная ссылка на почитать: semver.org
Вот чем хорош был svn, так вот этим :)
Если вы имеете в виду $Revision, то он бесполезен, так как относится к конкретному файлу, а не ко всему проекту.
Или я вас не понял, или вы что-то путаете.
В svn сквозная нумерация ревизий. Ревизия файла и проекта по сути одно и тоже.
В svn сквозная нумерация ревизий. Ревизия файла и проекта по сути одно и тоже.
svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html
Revision
This keyword describes the last known revision in which this file changed in the repository, and looks something like $Revision: 144 $. It may also be specified as LastChangedRevision or Rev.
Revision
This keyword describes the last known revision in which this file changed in the repository, and looks something like $Revision: 144 $. It may also be specified as LastChangedRevision or Rev.
>(а кто и зачем собрался держать код вне репозитория?)
Ну вот тут товарисчи держали код в репозитории...
Ну вот тут товарисчи держали код в репозитории...
>Не подойдёт для, например, PHP, так как вызывать пару тройку shell-комманд на каждый запрос — накладно.
Вот тут не только проблема в ПХП — зачем выполнять несколько команд при каждом запросе, если можно их собирать только когда это необходимо.
В гите есть замечательный .git/hooks/post-merge хук, в котором можно всю эту инфу единоразово положить в файл version.php (.rb, .py...) и подключать его.
Итого в коде всегда будет актуальная переменная (константа, класс) которая будет содержать эту информацию.
Спасибо за git describe!
Вот тут не только проблема в ПХП — зачем выполнять несколько команд при каждом запросе, если можно их собирать только когда это необходимо.
В гите есть замечательный .git/hooks/post-merge хук, в котором можно всю эту инфу единоразово положить в файл version.php (.rb, .py...) и подключать его.
Итого в коде всегда будет актуальная переменная (константа, класс) которая будет содержать эту информацию.
Спасибо за git describe!
Ну да, как вариант — использовать хуки… Вот только я не знаю — передаются ли хуки по pull/push, или для каждого клона их придётся прописывать заново?
Так как я всё ещё не определился, хранение номера версии в коде — это зло или благо? Может быть post-merge (или лучше pre-commit) хук, вычисляющий и записывающий номер версии в файл (и добавляющий его в коммит).
Я думаю, что такой вариант будет золотым компромиссом: и версии автоматом ставятся и в коде есть.
Но здесь есть одно НО: при создании тэга потребуется переписать этот и все последующие коммиты (а изменение истории — это совсем нехорошо, если эти коммиты уже ушли на гитхаб или ещё куда в паблик). Но это касается только случая, когда этот файл version.ext включен в репозиторий (не игнорируется).
Так как я всё ещё не определился, хранение номера версии в коде — это зло или благо? Может быть post-merge (или лучше pre-commit) хук, вычисляющий и записывающий номер версии в файл (и добавляющий его в коммит).
Я думаю, что такой вариант будет золотым компромиссом: и версии автоматом ставятся и в коде есть.
Но здесь есть одно НО: при создании тэга потребуется переписать этот и все последующие коммиты (а изменение истории — это совсем нехорошо, если эти коммиты уже ушли на гитхаб или ещё куда в паблик). Но это касается только случая, когда этот файл version.ext включен в репозиторий (не игнорируется).
>Так как я всё ещё не определился, хранение номера версии в коде — это зло или благо?
Так ничто не мешает этот файл добавить в .gitignore ) и не будет лишней мороки с коммитами
Можно написать 1 скрипт который будет «перебивать» версию и подключать его в нужных хуках, в зависимости от своего сценария деплоймента.
А вообще, зачем эта информация нужна на каждой странице? Можно сделать special-url для тестеров… заметят баг — откроют, скопипастят номер версии в тикет и всего то и делов.
Так ничто не мешает этот файл добавить в .gitignore ) и не будет лишней мороки с коммитами
Можно написать 1 скрипт который будет «перебивать» версию и подключать его в нужных хуках, в зависимости от своего сценария деплоймента.
А вообще, зачем эта информация нужна на каждой странице? Можно сделать special-url для тестеров… заметят баг — откроют, скопипастят номер версии в тикет и всего то и делов.
Не подойдёт для, например, PHP, так как вызывать пару тройку shell-комманд на каждый запрос — накладно.
Кроме этого, держать директорию .git доступную через веб сервер тоже как то не хорошо.
Мне хватает github.com/svenfuchs/gem-release
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полуавтоматическое выставление номера версии с помощью git