Отслеживание Git-ветвления и развертывания среды - PullRequest
Новая
       13

Отслеживание Git-ветвления и развертывания среды

3 голосов
/ 04 августа 2011

Мы перемещаем наш контроль версий из VSS в Git (и ОЧЕНЬ рады этому).Я пытаюсь определить лучшую стратегию в Git, чтобы отслеживать, какие версии нашего кода развернуты на каких блоках в нашей среде.До сих пор мы только посвятили нашу основную ветку GitHub исключительно для представления того, что находится в производстве.В этой ветви не произойдут коммиты, если только команда управления конфигурацией не сделает запись того, что было успешно применено в рабочей среде.

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

Я думаю, что теги были бы отличным решением, но как люди реализуют это?Допустим, у меня есть 3 среды QA с именами QA1, QA2, QA3.Если бы я только что развернул код из ветви origin / hotfix42 в коробку QA2, я бы мог использовать номенклатуру тегов, такую ​​как «QA2-060911_511pm», которая говорит мне, какая версия кода была развернута на каком ящике в какое время?Но если я это сделаю, моя база данных тегов со временем вырастет до сотен и даже тысяч.Поэтому, если бы я хотел найти текущую версию, развернутую в QA2, как бы выполнить запрос по всем тегам, чтобы найти самую последнюю?Или .... я бы всегда добавил дополнительный тег с именем QA2_Current?Но затем постоянно нужно удалять этот тег и добавлять его в другие версии по мере развертывания?

Существуют ли другие механизмы для добавления метаданных в коммиты?Например, могу ли я добавить переменную env в мои коммиты, а затем искать коммиты, где env = QA2?

Спасибо

Ответы [ 2 ]

2 голосов
/ 04 августа 2011

Практическое правило заключается в том, что вы используете теги для вещей, которые никогда не изменятся (например, версия 1.0.0 всегда указывает на один и тот же коммит), и используете ветки для вещей, которые меняются (например, «последняя» версия).

Поэтому я бы рекомендовал, чтобы текущая версия, развернутая в QA2, была обозначена git branch QA2 и перемещена соответствующим образом, добавив -f к команде. Нет необходимости выполнять сложные слияния, если вы просто используете его как «подвижный тег».

Временами, когда вы захотите выполнять слияния, а не просто перемещать ветку, это если вам нужно сохранить историческую последовательность того, что было развернуто в прошлом. В течение короткого времени вы можете использовать QA2@{1}, QA2@{2} и т. Д., Но в конечном итоге они стираются git gc.

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

0 голосов
/ 04 августа 2011

Чтобы ответить на ваш вопрос о поиске новейшего тега, если вы используете unix, вы можете запустить его, чтобы вывести список тегов, отсортированных по датам фиксации: 

git tag | xargs -I@ git log --format=format:"%ci %h @%n" -1 @ | sort

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

git branch | sed 's/^\*//' | xargs -I@ git log --format=format:"%ci %h @%n" -1 @ | sort
...