проверка всех git-тегов

Question

В настоящее время я рассматриваю переход на git, но не могу найти элегантное решение для использования в настоящее время svn-тегов. В моем текущем хранилище у меня есть

tags 
tags/1 
tags/1.1 
tags/1.n 
tags/live 
tags/library 
tags/library/1 
tags/library/2 

где 1-1.n являются выпуски, я сливаю последний релиз в живой и библиотека содержит библиотеки для каждой версии может использовать. Я понимаю, как создавать теги 1.n в git, но я изо всех сил пытаюсь понять, как создавать теги live и library.

Должен ли я иметь отдельное репо для этого и вытаскивать теги от 1-1.n в качестве вспомогательных модулей или может прямо сделать это?

Answer 1

Мне кажется, что live должен быть веткой, а не тегом. На всякий случай, когда вы не знаете: в отличие от svn, который рассматривает ветку и теги подобно простой операции копирования дерева (с единственным отличием, которое вы используете при работе с ними), ветви и теги git просто указывают на определенные коммиты, основное отличие состоит в том, что активная ветвь следует за фиксацией, тогда как теги всегда остаются на фиксации, которую они создали против.

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

Говоря в более общих терминах, большая вещь, которую вы теряете при переходе от svn в git, - это удобство заранее установленного рабочего процесса. Git позволяет вам следить за общими рабочими процессами svn и многое, многое другое, но вы можете легко сделать яичницу из вашей истории, если не используете какие-либо ограничения на использование git. Вы можете найти очень эффективный рабочий процесс here. Это не единственный возможный рабочий процесс, и он может быть даже не лучшим для вашей ситуации, но он может служить отправной точкой, из которой вы создаете свой собственный рабочий процесс. Например, в нашем магазине, который также перешел из svn, мы придерживались большинства наших коммитов на master, для которых они используют ветку develop, и мы помещаем вещи на ветку release вместо своих master. Таким образом, наш рабочий процесс в основном такой же, как у них, но с другим выбором имен для долгоживущих ветвей.