Использование Git в качестве источника контроля для веб-разработки и нескольких сред

Question

Маленький контекст: мы команда из 6 разработчиков, работающих над веб-приложением. С момента запуска мы использовали CVS в качестве нашей системы контроля версий на сервере Windows, используя ColdFusion w / Eclipse. В последнее время, несмотря на всю шумиху вокруг Git и распределенных систем, мы решили проверить это.

В качестве стандартного веб-приложения у нас есть локальная среда, в которой мы разрабатываем новые функции / исправления ошибок. Среда разработки, в которой мы стараемся все для первоначального тестирования QA. Этап, на котором мы отправляем функции / исправления, которые уже были протестированы в этой среде, должен максимально имитировать наши производственные серверы. Наконец все идет по живой системе в пустыне ...

Этот процесс иногда довольно болезненный, так как большая часть его выполняется с помощью FTP, а иногда нет, и мы часто сталкиваемся с конфликтами при фиксации, поскольку для проверки чего-либо требуется больше времени, чем обычно, или когда срочно требуется быстрое исправление ошибки.

Я немного смущен тем, как Git будет работать в этом случае, это, очевидно, не редкий сценарий, но большая часть того, что я обнаружил, не говорила об этом подробно.

Если я правильно понимаю, что локальные ветви играют важную роль в Git, я сначала клонирую репозиторий git, затем разветвляю, что-то исправляю и фиксирую все локально?

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

Если мои предположения верны, то главный вопрос - что происходит с постановкой. Очевидно, что некоторые функции / исправления требуют больше времени для тестирования, некоторые - более срочные и т. Д. Могу ли я просто сделать что-то вроде добавления определенных функций / веток в стадию для окончательного выхода из системы, а затем сделать то же самое с живого сервера ( потяните как они подписаны)?

Это довольно много, чтобы прийти из истории CVS ... любая помощь будет принята с благодарностью!

Answer 1

• Локальные ветви важны, потому что вы можете создавать столько, сколько хотите, и объединять их довольно легко.
• Отслеживание ветви (на самом деле локальная ветвь, следующая за удаленной отслеживающей ) гораздо более актуальны в вашем случае, так как вы позволяете формально связать локальную ветку переход к удаленному, для публикации цели (еще одна замечательная особенность DVCS: вы можете " publish " зафиксировать в одном удаленном репо или другом)

Идея состоит в том, чтобы определить:

• голое РЕПО для толкающих целей
  • репозиторий для разработчиков, где все разработчики могут отправлять свои текущие работы и / или извлекать работы у своих коллег (что-то вроде локального «центрального» репо, но существует множество других рабочих процессов , подобных описанному на этой странице книги ProGit )
  • пустое промежуточное репо, в котором промежуточная ветвь выдвигается с материалом для тестирования / проверки.
    Команда QA может клонировать этот репозиторий, чтобы получить промежуточный рабочий каталог, в котором они могут запустить и протестировать веб-сайт.
  • пустое хранилище на сервере в производственной среде.
    Менеджер prod может клонировать это, а затем rsync / ftp на реальные производственные серверы, которые будут управлять живым веб-сайтом.
    Примечание: у вас не должно быть DVCS на реальном производственном сервере. У вас должно быть только то, что вам нужно для запуска / мониторинга производственной среды.

Базовый рабочий процесс основан на проталкивании ветвей между этими средами (репозитории):

• в репозитории dev и staging, вы можете поддерживать несколько официальных общедоступных веток, примерно так же, как сопровождающий Git Хулио С. Хамано делает это со своим public, maint, следующие ветки ',' pu '.
• перед тем, как что-либо отправить в стадию, вы можете перебазировать свою работу в первую очередь поверх удаленной промежуточной ветки, чтобы решить локально любой конфликт и обновить ваш Работа локального разработчика с любым исправлением, обнаруженным / сделанным в рабочей области.
• переход от промежуточного к промежуточному продукту должен быть тривиальным (никаких конфликтов, так как на стороне репо-продукта никаких изменений не производится)
• вы можете определить хуки в промежуточном репо и prod repo, чтобы принимать только определенные ветви и отказываться от создания любых веток (в отличие от всех репо dev, где вы можете определить / толкнуть / вытащить столько веток, сколько вам нужно)