Git: я должен оформить заказ версии с тегом или мастера?

297
AdamJeffers

Общий вопрос вокруг Git.

Мы работаем в двухнедельных спринтах и ​​у нас есть 4 ветки:

разработать> Release-B-Name (тест)> Release-A-Name (бета)> мастер

Каждый спринт мы создаем новую ветку с некоторым именем (AZ).

Каждый квартал мы объединяем RC в master и помечаем этот код как готовый к работе.

Затем, на производственной коробке, мы выбираем и объединяем последнюю версию мастера (запустив git pull origin master), поэтому каждый квартал производство запускает последнюю и лучшую версию мастера. Это был исторический подход.

Вопрос: Должен ли я запускать / проверять основную ветку или помеченную версию master в рабочей коробке?

Я знаю, что работа с помеченной версией будет делать это в отсоединенном состоянии, но я не вижу проблемы с этим, за исключением случаев, когда нужно сделать исправление?

-1
Почему отрицательный голос? AdamJeffers 5 лет назад 0
Вероятно потому, что в этом вопросе отсутствует много контекста. Git - это система контроля версий. Используете ли вы git в качестве инструмента развертывания? Если да, то почему? И почему это важно, что вы находитесь в отдельном состоянии на производстве? Вы действительно намереваетесь совершать (и развивать) производство? Пожалуйста, отредактируйте, чтобы объяснить это. sleske 5 лет назад 2
Также возможно, что это целиком и полностью зависит от вашей компании, от того, являются ли помеченные версии «производственными выпусками» или должны ли производственные системы всегда иметь самую последнюю версию из того, что вы проверяете. На самом деле это не так легко от ответственности, кто не знаком с вашей группой или процессами компании. Mokubai 5 лет назад 1
Да, очень действительные баллы! Буду обновлять вопрос. AdamJeffers 5 лет назад 0
Может быть, посоветуйтесь с владельцем, где он размещает свой готовый код и что он хочет увидеть на Prod. Это будет зависеть от вашего проекта, поэтому вряд ли кто-то даст вам правильный ответ, просто несколько догадок. Seth 5 лет назад 0
Обновили вопрос;) AdamJeffers 5 лет назад 0
Спасибо за обновления. Еще одна вещь: «на производственной коробке мы выбираем и объединяем последнюю версию master». Зачем "сливаться"? Если вы проверяете только последнюю версию мастера, это всегда должно быть ускоренной проверкой. Почему вы получаете слияния? Это звучит опасно ... sleske 5 лет назад 0
@sleske. Процесс по-прежнему называется слиянием: `git merge --ff-only origin / master` TRiG 5 лет назад 0
@TRiG: Да, я надеюсь, что это то, что OP означает «слияние». sleske 5 лет назад 0
@sleske и @TRig ... Мне еще не приходилось этого делать, но когда я видел, как мой менеджер проходит через этот процесс, я только видел, как он заходил в окно prod и запускал `git pull origin master`. Насколько я знаю, это просто "git fetch", а затем "git merge"? AdamJeffers 5 лет назад 0
Да я вижу. Я думаю, что теперь понимаю. Я постараюсь написать ответ завтра. sleske 5 лет назад 1
@Sleske ... отлично, спасибо! AdamJeffers 5 лет назад 0
Тэги обычно используются для релизов. И основная ветвь часто просто отражает текущее состояние кода, который обычно является тем, что выпущено. Тем не менее, все это действительно произвольно и основано на мнении, основанном на вашей внутренней практике. JakeGould 5 лет назад 0
@JakeGould: Да, как вы пишете, это зависит от используемого процесса. В частности, в отношении «master» оба подхода, которые вы перечисляете, являются общими: master для текущего состояния кода (это значение по умолчанию, слабо подразумеваемое git) или master для стабильной версии («stable master», например, используемый популярная модель [Git flow] (https://nvie.com/posts/a-successful-git-branching-model/) модель). sleske 5 лет назад 0

1 ответ на вопрос

1
sleske

Отказ от ответственности: лично я довольно скептически отношусь к использованию Git в качестве инструмента развертывания. Реальный инструмент сборки / развертывания будет предлагать много вещей, которые Git не делает: правила создания версий, компиляцию / предварительную обработку, управление правами доступа к файлам и т. Д. Если вы «развертываете» с помощью Git, эти шаги обычно должны выполняться вручную, что отстой. Однако вы, похоже, в принципе удовлетворены процессом развертывания, поэтому я перестану с этим спорить.

Чтобы ответить на ваши вопросы:

Вопрос: Должен ли я запускать / проверять основную ветку или помеченную версию master в рабочей коробке?

Оба могут работать, но я бы предпочел использовать теговую версию . Вытащенные файлы будут точно такими же, поэтому никакой разницы нет. Однако в некоторых случаях использование версии с тегами безопаснее:

  • Если кто-то должен стремиться освоить время между пометкой и развертыванием, вы все равно получите правильную версию.
  • Если позже кто-то просто запустит git pullпроизводство, с настройками по умолчанию и masterпроверкой Git получит последнее состояние master(что бы это ни было). Если тег извлечен, ничего не изменится.

Я знаю, что работа с помеченной версией будет делать это в отсоединенном состоянии, но я не вижу проблемы с этим, за исключением случаев, когда нужно сделать исправление?

Я действительно надеюсь, что вы не намекаете на то, что вы собираетесь устанавливать (и, возможно, даже разрабатывать) исправления в процессе производства? Если да, то, пожалуйста, не надо :-).

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


Наконец, несколько советов:

Затем на производственном ящике мы выбираем и объединяем последнюю версию master (запустив git pull origin master)

Даже если вы настаиваете на использовании Git для развертывания, это не очень хорошая идея git pull, потому что git pullона автоматически выполнит слияние, если ранее была проверена неправильная ветвь (или если у вас даже есть локальные коммиты, чего, надеюсь, нет). Объединение приведет к тому, что у вас будет (непроверенный) набор данных из разных веток. Скорее, я бы порекомендовал вам использовать:

git fetch git checkout MY_VERSION_TAG 

Таким образом, вы получите именно файлы MY_VERSION_TAG. Кроме того, я настоятельно рекомендую вам проверить наличие локальных изменений git statusперед использованием. Если таковые обнаружены, исследуйте их перед развертыванием.

Спасибо за подробный ответ. Не уверен, почему кто-то за тебя проголосовал ?! Когда я говорю «исправление», я просто имею в виду исправление локально, тестирование его, а когда оно проходит, «вишня» в мастер, который затем может быть извлечен. Но если я запускаю тег, я не могу просто вытянуть это исправление, как вы говорите. Я подумаю над этим;) AdamJeffers 5 лет назад 0
@AdamJeffers: Хорошо, разработка таких исправлений звучит разумно. Также я не вижу проблем с развертыванием. Вы просто относитесь к исправлению как к любому выпуску (который вы должны в любом случае): вы помечаете его (что-то вроде «2018-q3-hotfix33»), а затем извлекаете этот тег, как я описал выше. sleske 5 лет назад 0
Ах, еще одна вещь: очевидно, что исправление должно быть разработано (локально) поверх текущей рабочей версии (т. Е. Проверить тег pro, основать на нем ветвь, а затем исправление). Протестируйте, разверните и добавьте тег pro в ветку dev. Ввод вишни в производство - ИМХО очень плохая практика (потому что вы не используете то, что тестировали). sleske 5 лет назад 0
Да это я и имел ввиду;) AdamJeffers 5 лет назад 0