Как в git clone указать определённую версию, а не последнюю?

Question

[Сергей Пуговкин]

Как лучше устанавливать что-то из гитхаба.
Например, сейчас делаю так:

cd /usr/local/src && git clone https://github.com/openresty/lua-resty-string && cd lua-resty-string && make LUA_VERSION=5.1 install

А если надо определённую версию, а не последнюю? Как?

Comments

[Cabac_B]

SmInc, не только ветка.
еще и коммит и тэг - это все можно тоже трактовать как версия.

[Модератор]

Сергей Пуговкин дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац).
В противном случае, ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.

[Cabac_B]

SmInc,

Ну давай копайся в коммитах, не залезая в Branch, а я залезу в Branch и найду за 3 секунды.

С бранчами, как правило, вы сможете увидеть только мажорные версии в их текущем (последнем) состоянии, если поддержка этих версий еще ведется.

Предназначение бранча - другое.
Например, сравниваем количество бранчей и количество релизов (тегов):

https://github.com/docker/docker-ce
https://github.com/kubernetes/kubernetes

Можно увидеть примерно ту же ситуацию и с ядром Linux и пр.

Бранч != Версия.

SmInc,

Не надо усложнять и писать комментарии в стиле "а еще бывает файл под названием Govnodoki.md и в нем на 215-й строке указана 18 версия, я сам точно так делал в своем проекте, так что это тоже надо запомнить, ведь и так бывает"

Не коменты нужно использовать.
Для этого есть теги и коммиты.

SmInc,

Ну давай копайся в коммитах, не залезая в Branch, а я залезу в Branch и найду за 3 секунды.

бранчи - хороши под полной методологией GitFlow, когда весь процесс разработчки рассчитан, что ведется поддержка нескольких старых версий параллельно разработке новой версии. Типичный пример - Linux, для которого собственно и был придуман весь git. Но даже в его репе невозможно найти на данный момент бранчи для очень старых версий. Но по тегам вы их можете отыскать легко.

Ну а как бранчей нет вовсе?
При поддержки одной единственной-единственной актуальной версии - зачастую так и бывает.

Точнее есть - бранч dev (текущая разработка, всегда последняя версия), который сливается время от времени и бранчем production (текущая версия в эксплуатации). И изредка возникающие и исчезающие брачи fix.

И что вы там найдете?

Тогда старую версию можно найти только по коммитам.
И тут будет хорошо если автор удосужился пометить коммит тэгом, написав в нем версию.

Недаром, технические средства поддержки вендоринга (управления зависимостями от внешних пакетов) в той же NodeJS (npm install) и в Go (dep ensure) в качестве зацепок для фиксирования версий используют как тэги так и коммиты. Но использование бранчей - нужно указывать там в явном виде.

Бранчи - это для других целей.
Бранч - это в общем случае "мажорная версия с последней минорной подверсией, да и то - пока она в работе и поддержка не завершена"