Преобразование ветки git в тег git
Я ищу лучший и самый безопасный способ конвертировать ветку git в тег git. При ручном портировании через репозиторий SVN я в основном копировал все наши ветви, и у нас была ветка для каждого второстепенного выпуска (1.1, 1.2, 1.3), что, честно говоря, было не лучшим способом сделать это, но ради скорость, мне было удобнее с ветками, чем с тегами в то время. Теперь у меня есть ветки 1.5, 1.6, 1.7, 1.8, однако, поскольку в любой момент времени у нас развернута только 1 версия кода, мне, вероятно, нужна только последняя версия, чтобы быть веткой, если для этой версии нужны исправления. развернут. Поэтому я ищу лучший способ конвертировать ветку git в тег git. Я думаю, что у меня есть способ, но я уверен, насколько он хорош.
Пока что я сделал для каждой ветви, которую я хочу преобразовать в тег, я проверил, чтобы убедиться, что в тех ветках, которые не находятся в основной ветви, нет коммитов, поэтому я сделал:
git log 1.5 ^master
git log 1.6 ^master
git log 1.7 ^master
Все это не возвращает мне ничего, что, я считаю, означает, что все коммиты в этих ветвях существуют в master. Я сделал это, потому что предположил, что если в тех ветвях, которые не были в master, были коммиты, я бы их потерял при преобразовании ветви в тег, так как тег - это просто "указатель" на один коммит, а не строка разработки. С этим, казалось бы, хорошим, я предполагаю, что мне просто нужно сделать:
git tag 1.5v 1.5
git tag 1.6v 1.6
git tag 1.7v 1.7
Тогда мне просто нужно будет удалить ветки локально и отправить эти изменения в удаленный репозиторий. Это лучший способ конвертировать ветку git в тег git?
Также у меня есть одна проблема: если кто-то создал ветку, скажем, 1.7 (которую никто не должен делать), и он извлечет изменения, которые удаляют эту ветку, смогут ли они объединить эти изменения в другую ветку (скажем, master) или же такого рода? сломать ветку, которую они создали? Это случай, который не должен происходить, так как никто не должен создавать ветки вне какой-либо версии ветки, кроме последней версии, в данном случае 1.8, но люди не всегда следуют процедуре должным образом, поэтому я хочу убедиться, что есть способ чтобы исправить это, если это произойдет.
2 ответа
Краткий ответ: это не проблема. И создавать теги так, как вы предлагаете, это нормально, хотя я предлагаю вам использовать -m возможность создать аннотированный тег с комментарием (см. man git-tag), поскольку это создаст тег "первого класса", который будет использоваться git describe и т.д. без дополнительных аргументов.
Длинный ответ: Удаленные филиалы не влияют на локальные филиалы напрямую. Если я создаю ветку из ветви или тег из вашего общего репо, когда вы удаляете эту ветку и извлекаете ваше репо, я увижу, что ваша ветвь исчезла, но моя ветвь все еще завершена в моем репо.
Ветви - это только символические имена для коммита в git-репо, когда вы фиксируете HEAD, а ветвь, над которой вы работаете, указывает на новый коммит. Тег также является символическим именем для коммита, но его нельзя изменить (хотя вы можете удалить его, но его нельзя изменить), поэтому он указывает на фиксированное положение в истории, а ветвь указывает на движущуюся голову. одной линии в истории. Поскольку коммиты в git имеют ноль, один или несколько родительских коммитов (ноль для начального коммита, один для обычного коммита, более одного для слияния), даже если исходная ветка или тег удаляются с удаленного компьютера, у вашего локального репо все еще есть указатель на вашу локальную ветку, и из этого вы можете найти общего предка (предполагая, что ветви связаны в первую очередь), так что вы все равно можете объединить изменения, сделанные в любой из ваших ветвей, в master.
Переход от svn к git может поначалу немного запутать. Похоже, вы все еще думаете в терминах SVN, делая все более запутанным. Я думаю, что будет проще, если вы будете думать о git больше как о продвинутой файловой системе (такой, какой был Линус Торвальдс, когда писал ее), а не как инструмент управления исходным кодом. Я также предлагаю вам потратить некоторое время, чтобы прочитать (или пролистать) git для компьютерных ученых, это не так страшно, как кажется; а лучшее понимание того, как это на самом деле работает, поможет вам думать о "правильном пути".;)
Насколько я понимаю, вы хотите создавать теги вместо веток и тем самым мешать другим продолжать фиксацию в этих ветках.
К сожалению, вы не можете помешать людям создавать филиалы там, где они хотят, тем более что Git - это децентрализованная VCS. Тем не менее, вы можете решить, можно ли отправить коммит в центральный репозиторий. Таким образом, вы могли бы написать хуки, которые запрещали бы коммиты, которые имеют определенные коммиты у своих предков.