Управление ветвями для самостоятельного репо и тестирования

Question

Я понимаю, что это звучит не слишком ясно, но я все еще в замешательстве. Я изучаю книгу Git, но не уверен на 100%, что полностью ее понял. Если кто-то считает, что информация отсутствует, сообщите мне, чтобы я мог дополнить ее.

---

На прошлой неделе мы создали собственный хост-репозиторий и сервер git. Этот репо является основным и является тем, что в настоящее время используется в промежуточной среде. С этого момента мы вручную переводим на производство.

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

Что мы стремимся сделать: создайте ветви из этого мастера, чтобы позволить людям писать код, но если ветви могли бы храниться локально на пользовательских машинах, а не на тестовом сервере, где находится главное репо, это было бы идеально.

Для тестирования кода: как бы это сделать? Будет ли толкать измененный файл (ы) из локальной ветви на мастер и попробовать там? Будет ли на самом деле просто создавать несколько веток на сервере, но локально переключаться на эти ветви?

Код не может быть протестирован независимо от чего-либо еще, поэтому его нужно будет добавить в основную / развернутую версию в любом случае.

Мне было поручено настроить git для нашей среды, поэтому я стараюсь сделать это максимально безболезненным и простым.

Answer 1

Git и управление версиями могут поначалу сбивать с толку, поэтому я постараюсь ответить на конкретные вопросы вашего вопроса индивидуально:

" [..] чтобы внести изменения, кто-то просто обращается к файлу и вносит необходимые изменения на сервере [...] "

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

" [...], если ветви могли храниться локально на компьютерах пользователей, а не на тестовом сервере, где главное репо [...] "

В этом весь смысл Git и контроля версий. Вы должны разместить свои файлы в своем репозитории Git, и у каждого из ваших разработчиков будет клон локальной копии репо (git clone). Это позволяет им работать с собственной изолированной копией кода, время от времени pull с последними изменениями из origin. Затем они push вернутся к origin, когда код будет завершен.

" Что мы хотим сделать: создать ветки из этого мастера, чтобы позволить людям писать код на ".

Здесь вы спрашиваете о Git Flow . Вы должны создать одну ветвь из master, называемую develop, и ветвь каждого из ваших feature ветвей из develop. Когда отдельная функция завершена, она должна быть объединена обратно в develop.

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

" Для тестирования кода: как бы это сделать? "

« Код не может быть протестирован независимо от чего-либо еще, поэтому его необходимо добавить в основную / развернутую версию в любом случае. »

Вы хотите проверить на develop. Когда все функции кандидата на выпуск (группа изменений, которую вы в конечном итоге хотите развернуть в рабочей среде) будут завершены, вы захотите развернуть ветку develop в среде тестирования. Здесь вы можете протестировать эту версию develop, в то время как другие разработчики могут свободно загружать более поздние версии develop в среду разработки - тестовая среда не будет обновляться.

После того, как вы будете удовлетворены тестированием в среде тестирования - когда вы захотите развернуть код в рабочей среде, вы можете наконец объединить develop обратно в master (в идеале использовать release ветвь, если вы обрабатываете правильные графики выпуска). master затем подключается к вашей производственной среде.

<ч />

Следуя Git Flow, вы когда-либо развернете код на master только после того, как он будет тщательно протестирован, и, таким образом, непроверенный код никогда не превратится в рабочий.