Управление двумя локальными репозиториями GIT с одного пульта

Question

Я закончил тихим беспорядком с моим репозиторием на github, и я ищу несколько советов о том, как разобраться с этим и предотвратить его повторение в будущем.Начну с того, что я системный парень, а не разработчик, но я отвечаю за управление репозиториями.

Моя среда выглядит следующим образом: 1 сервер разработки, 1 рабочий сервер и 1 репозиторий github.

Моя текущая проблема: и серверы разработки, и производственные серверы используют один и тот же репозиторий github.Один из наших разработчиков поместил код непосредственно в мастер github, который в настоящее время работает на сервере dev, в то же время, локальные изменения были внесены в сервер prod.Новый код на dev / remote не готов к работе, и мне нужно перенести локальные изменения из рабочей среды в github и развернуть на сервере dev без перезаписи нового кода на dev.

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

Answer 1

Чтобы разобраться в текущем беспорядке:

1. Получить код с сервера prod, отправленного на GitHub.Так как в настоящее время в master есть другие вещи, мы перейдем к новой ветке prod.На прод-сервере:

   a.git checkout -b prod для создания новой prod ветви.

   b.git commit чтобы зафиксировать ваши изменения в локальном репозитории prod git.

   c.git push -u origin prod чтобы отправить ваш код на GitHub.

2. Теперь давайте объединим это с master.На компьютере разработчика:

   a.git checkout master и git pull, чтобы убедиться, что вы в курсе.

   b.git merge prod для объединения ветки prod в ветку master.

   c.git push, чтобы переместить объединенную главную ветку в GitHub.

3. Теперь у вас есть ветвь prod, представляющая производство, и ветвь master, которая содержит все вашиизменения.Это зависит от вас, если вы хотите переименовать их, продолжить работу разработчика над мастером, подтолкнуть мастера к продукту или что-то еще.

---

Как избежать этого в будущем:

• Никогда не редактируйте код в рабочей коробке.
• Любой код, который передается в рабочую версию, должен быть помечен версией выпуска.Если у вас нет схемы управления версиями, вам следует начать.Это не должно быть необычным - вы можете просто начать с 1 и идти оттуда, если хотите.
• Реализация процесса выпуска.Например, мастер должен содержать только проверенный код, готовый к выпуску.И когда код выпущен, мастер помечается, а затем этот тег развертывается в производстве.Или что-то типа того.Выясните, что работает для вас.
• В связи с процессом выпуска разработайте политики, в которых должен быть размещен код.В большинстве организаций разработчики проталкивают в ветку, например feature-a, а затем открывают запрос на извлечение для мастеринга, когда код протестирован и готов к работе.

Answer 2

Самое простое решение - создать новую ветвь с именем production, указывающую на коммит, который вы хотите развернуть на рабочем сервере, а затем проверить эту ветвь на производственном сервере.

Разработчикизатем свободно нажмите master, который является веткой по умолчанию в Git.Чтобы обновить производственный сервер до более новой версии кода, вы можете продвинуть ветку production до коммита, который вы хотите развернуть, нажать production на GitHub, а затем выполнить git pull на производственном сервере.

Вы можете настроить GitHub для наложения ограничений на ветку production, чтобы разработчики не могли использовать ее и разрешать только авторизованным пользователям изменять эту ветку.