Я в процессе перехода от svn к git, и мне интересно, как управлять нашими локальными веб-серверами разработки вместе с новой системой git.Как управлять ветвями git с локальными веб-серверами?
В настоящее время разработчик может иметь несколько проверок ветви разработки. Каждый из этих контрольных каталогов сопоставляется с веб-сервером с различными виртуальными хостами.
Например, у разработчика bob может быть 3 проверки dev для различных билетов. Каждый из этих проверок имеет свой собственный виртуальный хост bob.dev1.localhost, bob.dev2.localhost и bob.dev3.localhost.
Когда все будет сделано с билетом, они помечают билет, на котором размещаются изменения, и переносят билет на QA. Это кажется относительно прямым.
Теперь, с git, с несколькими каталогами проверки не имеет смысла. Разработчик может просто разветвить ветвь разработки и работать на чистом слайде и просто проверить другую ветвь, когда им нужно изменить шестерни.
Есть ли способ, чтобы локальные веб-элементы dev указывали на конкретные локальные проверки git? Например, разработчик создает новую ветвь, вносит свои изменения и затем передает имя ветки как часть хоста, а затем всякий раз, когда кто-то попадает на веб-сервер, локальная ветка проверяется, если она еще не существует, и мы можем передавать определенные URL-адреса на билеты? Например, bob.branch1.localhost, bob.branch2.localhost.
Если ничего из этого не имеет смысла, я не удивлюсь. Если у вас есть предложения о том, как это сделать, основываясь на вашем собственном процессе разработки, я бы хотел его услышать.
Мы всегда старались избежать внесения изменений в утвержденный билет, не относящийся к QA. Это предотвратило необходимость пропустить ревизии при слиянии с багажником в случае, если что-то не получило QA после тестирования. Это не очень распространенная практика? – boojer
Не с dvcs. git называет эквивалент dvcs svn's commit «push», и Боб имеет полный контроль над тем, что отталкивается от его репо. Если QA хочет его работы, он выполняет свою работу в своем собственном репо, синхронизирует его с ответом QA филиала, который хочет, чтобы он нажал, и просто толкает, и только коммиты QA хотят видеть, структурированные именно так, как QA хочет их, для репо QA. То, что происходит в репо Боба, - дело Боба, нет никаких оснований рассматривать это, чем заметки на его столе. – jthill
Нормально ли, что несколько разработчиков объединяют свои ветви функций в общую ветвь QA? Что делать, если объединенная ветвь функции не выполняет QA и каким-то образом влияет на качество других ветвей функций, которые объединяются. Как удалить объединенную ветвь, которая не удалась из ветви QA? – boojer