Правильный рабочий процесс Git — основа успешного программного проекта. Итак, каков правильный рабочий процесс, которым должны заниматься все участники проекта?
Давайте разберем его шаг за шагом.
Первоначально ваша организация создает репозиторий для вашего проекта. ЭТО НИКОГДА НЕ ДОЛЖНО БЫТЬ ВЕТВЬЮ, КОДЕР НАЖИМАЕТ СО СВОЕЙ ЛОКАЛЬНОЙ МАШИНЫ.
Затем кодировщик разветвляет репозиторий этой организации, чтобы создать свой собственный репозиторий под своим именем.
Затем на локальном компьютере кодер клонирует свой личный репозиторий в новый каталог для этого проекта.
В этом каталоге на локальном компьютере кодировщик должен создать новую ветку для функции, которую он создает, давайте использовать интерфейс в качестве примера.
(Работает из ветки переднего плана) Кодер начнет вносить изменения. Как только эти изменения будут завершены, пришло время нажать... но подождите, есть кое-что еще. Кто-то еще в организации мог вносить изменения в свою локальную машину, завершить и должным образом перенести свои изменения на мастер организации (позже мы обсудим этот процесс с точки зрения нашей внешней ветки). Таким образом, это означает, что обновленная версия мастера организации не имеет внешних изменений, но также имеет завершенные изменения в проекте, которых кодер не имеет на своем локальном компьютере. Что делать кодеру?
Не бойся, юный кодер, есть решение. Кодировщик, если он еще не добавлен, добавит восходящий удаленный
git remote add upstream ‘organization github link’
Затем кодер извлекает из этой ветки и исправляет конфликты слияния. Это предоставит кодировщику текущую версию основного кода организации вместе с их собственными изменениями внешнего интерфейса.
Настало время кодировщику перейти к своему собственному репозиторию в Интернете. Это так же просто, как из каталога проекта локального компьютера кодера сказать
git push origin frontend
(front end — это название ветки, предназначенной для работы над front end разработкой)
Этот толчок опубликует изменения в личном репозитории кодеров, например, на Github.
Затем кодировщик должен убедиться, что это подходящие изменения, которые они хотят отправить в проект организации. Предполагая, что изменения правильные, они должны быть, если кодер следовал нашему правильному руководству по рабочему процессу github, кодер сделал бы запрос на извлечение в репозиторий организации из своего собственного.
Это создаст уведомление для организации о том, что кодировщик хочет обновить репозиторий организации. Кто-то, помимо кодера, выполнял проверку запрошенного запроса на включение. Предполагая, что все правильно, организационный контролер примет изменения. Бум, изменения внешнего интерфейса теперь применяются к репозиторию организации. Что, если изменения внешнего интерфейса не соответствуют стандартам организации? Что ж, организация может отклонить этот запрос на вытягивание, добавив комментарии о том, что кодеру нужно исправить, и повторять этот процесс до тех пор, пока изменения не будут правильными.
Вуаля, теперь кодировщик обновил ветку организации своими собственными данными, следуя правильной процедуре рабочего процесса. Я надеюсь, что это осветило все, с чем у вас, возможно, были проблемы. Спасибо за чтение. Продолжайте кодить, друзья мои.
