Простая модель ветвления Git для сайта

Question

Может кто-нибудь предложить простой git-режим ветвления для разработки сайтов. Я видел несколько дискуссий об успешных моделях git-ветвления, к сожалению, все они очень сложны для нашего случая. Большинство моделей ветвления подходят для программ с версиями и циклами выпуска.

Наша компания управляет несколькими веб-порталами. На этих сайтах работают 5 человек. В большинстве случаев 2-3 человека могут работать на одних и тех же сайтах, но в разных разделах (вероятность конфликта близка к нулю). У нас нет версий или циклов выпуска. Программист разработает определенный раздел, после чего он будет передан другому человеку, который напишет контент для раздела и выполнит SEO. Как только это будет сделано, раздел будет загружен на общедоступный веб-сайт. В то же время другой программист может работать над обновлением существующего раздела. Если сообщается об ошибке или ошибке, она будет немедленно исправлена ​​и загружена.

Обычно каждую неделю добавляются / обновляются 2-3 новых раздела.

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

Обновление Разве плохо создавать отдельную ветку для каждого раздела? Другими словами, сколько разветвлений считается слишком большим?

Answer 1

Мне кажется, что вам действительно нужно улучшить свою рабочую модель и процесс. Git - это не решение проблем с процессами, это инструмент, который должен поддерживать выбранный вами процесс.

Даже если вы утверждаете, что у вас нет циклов выпуска, у вас все еще есть выпуски: по крайней мере, рабочая копия в производстве должна рассматриваться как выпуск / версия. Ничто не мешает вам выпускать 10 выпусков в неделю, если это приемлемо с точки зрения контроля качества / тестирования.

Несколько баллов за мысль:

• На производственном сайте всегда должен быть клон 1: 1 в ветви (будь то мастер, релиз или что-то еще)
• «Выпуск», запущенный на производственном сайте, всегда должен иметь тег в управлении версиями для отслеживания.

Для чего это стоит, я думаю, что вы описываете модель, как это: http://nvie.com/posts/a-successful-git-branching-model/.

Answer 2

Вы говорите, что создаете ветки только для изменений дольше двух недель, но технически локальная копия каждого разработчика - это отдельная ветка, особенно с DVCS, подобным git. Я предполагаю, что ваша официальная основная ветвь не совпадает с тем, что находится в производстве, потому что вы используете эту ветку для обмена изменениями между программистом и создателем контента. В вашей ситуации с таким коротким циклом выпуска я бы сделал так, чтобы эти два сотрудника поделились своими локальными репозиториями с друг с другом , полностью пропустив центральный репозиторий, пока он не будет протестирован и готов к работе. Таким образом, вы автоматически получаете столько веток разработки, сколько вам нужно, и ваш официальный центральный репозиторий остается чистым.

Если это слишком сложная задача для вашей группы, вы всегда можете создать ветку production, которая будет получать только исправления ошибок напрямую, и объединять ее с основной веткой, когда она находится в стабильной точке для запуска в производство. Таким образом, ваши разработчики по-прежнему в основном работают из центральной главной ветки, как они привыкли.

Answer 3

У вас довольно последовательный цикл разработки, так что вы правы: вам не нужно множество ветвей функций.

Простая модель:

*--*--*--*---*   (master, for prod)
    \       /
     *--*--*--* (dev, for current development)

Вопрос:

Когда есть ошибка в prod ('master', живой сайт), вы можете исправить ее на dev ветке и включать все, что находится в разработке?

Потому что, если вы не можете, это означает, что у вас есть изменения в master, должны быть немедленно объединены в dev.Если это исправление выполняется быстро, вам даже не нужна ветка 'fix'.

Другими словами, вам не нужна вся сложная модель " Удачной модели ветвления Git».

Answer 4

Если сложность является проблемой для вас, посмотрите на Mercurial как замену GIT.

GIT и Mercurial используют эквивалентную распределенную модель VCS, однако Mercurial, как правило, проще в использовании и не раскрывает большую часть базовой сложности для пользователя.

Посмотрите на ответына этот вопрос В чем разница между Mercurial и Git?