Использование Git в качестве источника управления для веб-разработки и множественной среды

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

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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

Основной рабочий процесс основан на нажатии/вытягивании ветвей между этими средами (РЕПО):

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