Рабочий процесс Forking Workflow
Рабочий процесс с форками принципиально отличается от других популярных рабочих процессов Git. В этом рабочем процессе каждый разработчик получает собственный репозиторий на сервере, вместо того чтобы использовать единый репозиторий на стороне сервера в качестве «центральной» базы кода. Таким образом, каждый автор имеет не один, а два репозитория Git: один закрытый локальный и один публичный на сервере. Рабочий процесс с форками чаще всего встречается в публичных проектах с открытым исходным кодом.
Основное преимущество рабочего процесса с форками заключается в том, что поступивший код можно интегрировать, не отправляя его в единый центральный репозиторий. Разработчики отправляют коммиты в собственные репозитории на сервере, в то время как официальный репозиторий обновляется только силами пользователя, ответственного за поддержку проекта. В итоге такой пользователь может принимать коммиты от любых разработчиков, не предоставляя им доступ для записи в официальную базу кода.
В рабочем процессе с форками обычно используется модель ветвления, принятая в Git-flow. То есть для завершенных функциональных веток выполняется слияние в исходный репозиторий пользователя, ответственного за поддержку проекта. В результате мы получаем распределенный рабочий процесс для гибкой и безопасной совместной работы крупных органичных команд (включая недоверенных третьих лиц). Кроме того, этот рабочий процесс оптимален для проектов с открытым исходным кодом.
Порядок действий
Подобно другим рабочим процессам Git, рабочий процесс с форками начинается с создания официального публичного репозитория, хранящегося на сервере. Однако когда к работе над проектом приступает новый разработчик, он не клонирует официальный репозиторий напрямую.
Вместо этого он делает форк официального репозитория, чтобы создать его копию на сервере. Эта новая копия становится его собственным публичным репозиторием: другим разработчикам не разрешается отправлять туда коммиты, но они могут извлекать оттуда изменения (вы скоро поймете, почему это важно). Создав копию официального репозитория на сервере, разработчик выполняет команду git clone, чтобы скопировать его на локальную машину. Как и в случае с другими рабочими процессами, этот репозиторий становится закрытой средой разработки.
Чтобы опубликовать локальный коммит, разработчик отправляет его не в официальный репозиторий, а в собственный публичный. После этого он создает запрос pull для переноса кода в главный репозиторий, чтобы сообщить пользователю, ответственному за поддержку проекта, что обновление готово к интеграции. Запрос pull также выступает в качестве удобной ветки обсуждения в тех случаях, когда с поступившим кодом возникают проблемы. Ниже приводится пошаговый пример этого рабочего процесса.
Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
1. Разработчик делает форк «официального» репозитория, расположенного на сервере, и в результате получает собственную копию репозитория на сервере.
2. Разработчик клонирует созданную копию на сервере в локальную систему.
3. В локальный клон добавляется удаленный путь к «официальному» репозиторию Git.
4. Создается новая локальная функциональная ветка.
5. Разработчик вносит изменения в новую ветку.
6. Для изменений создаются новые коммиты.
7. Разработчик отправляет ветку в собственную копию репозитория на сервере.
8. Разработчик открывает запрос pull для переноса кода из новой ветки в «официальный» репозиторий.
9. Запрос pull на слияние подтверждается, после чего выполняется слияние с исходным репозиторием на сервере.
Чтобы интегрировать функцию в официальную базу кода, пользователь, ответственный за поддержку проекта, помещает изменения автора в свой локальный репозиторий, проверяет, не нарушают ли они работу проекта, выполняет их слияние со своей локальной главной веткой (main), после чего отправляет main ветку в официальный репозиторий на сервере. После этого поступивший код становится частью проекта, и другие разработчики должны получить его из официального репозитория, чтобы синхронизировать свои локальные репозитории.
Важно понимать, что понятие «официальный репозиторий» в рабочем процессе с форками — простая условность. Официальным его можно назвать лишь по той причине, что он выступает публичным репозиторием пользователя, ответственного за поддержку проекта.
Сравнение создания форков и клонирования
Важно отметить, что репозитории с форками и создание форков не требуют специальных операций. Форки репозиториев создаются стандартной командой git clone. В большинстве случаев форки репозиториев являются «клонами на сервере», а для их размещения и управления ими обычно используют сторонний сервис Git, такой как Bitbucket. Отдельной команды Git для создания форков репозиториев не существует. При клонировании, по сути, происходит копирование репозитория и его истории.
Ветвление в рабочем процессе с форками
Собственные публичные репозитории — это просто удобный способ поделиться ветками с другими разработчиками. Пользователям все равно следует отделять функции с помощью веток, как это происходит в рабочем процессе с функциональными ветками и в Git-flow. Разница заключается лишь в том, как этими ветками можно поделиться. В рабочем процессе с форками их помещают в локальный репозиторий другого разработчика, а в рабочих процессах с функциональными ветками и Git-flow — в официальный репозиторий.
Форк репозитория
В проекте, где используется рабочий процесс с форками, каждому новому разработчику нужно создать форк официального репозитория. Как уже говорилось ранее, создание форка — это обычная операция git clone. Для создания форка нужно установить SSH-соединение с сервером и выполнить команду git clone, чтобы скопировать репозиторий в другое место на сервере. В популярных сервисах размещения Git, таких как Bitbucket, предусмотрены функции создания форков репозитория, с помощью которых можно автоматизировать этот шаг.
Клонирование форка
В проекте, где используется рабочий процесс с форками, каждому новому разработчику нужно создать форк официального репозитория. Как уже говорилось ранее, создание форка — это обычная операция git clone. Для создания форка нужно установить SSH-соединение с сервером и выполнить команду git clone, чтобы скопировать репозиторий в другое место на сервере. В популярных сервисах размещения Git, таких как Bitbucket, предусмотрены функции создания форков репозитория, с помощью которых можно автоматизировать этот шаг.
Если для размещения таких репозиториев используется Bitbucket, разработчику, занятому в проекте, потребуется создать аккаунт Bitbucket и клонировать свой форк репозитория с помощью следующей команды:
git clone https://user@bitbucket.org/user/repo.gitДобавление удаленного подключения
В то время как в других рабочих процессах Git используется одно удаленное подключение, которое указывает на центральный репозиторий, рабочему процессу с форками требуется связь с официальным репозиторием и личным репозиторием разработчика на сервере. Хотя эти удаленные подключения можно назвать как угодно, обычно подключение к форку репозитория называется origin (создается автоматически при выполнении команды git clone), а подключение к официальному репозиторию — upstream.
git remote add upstream https://bitbucket.org/maintainer/repoВам потребуется самостоятельно создать удаленное подключение upstream с помощью указанной выше команды. Это позволит вам без труда поддерживать актуальность локального репозитория по мере выполнения официального проекта. Обратите внимание: если в вышестоящем (upstream) репозитории включена аутентификация (т. е. он не является репозиторием открытого исходного кода), вам нужно будет указать имя пользователя, например:
git remote add upstream https://user@bitbucket.org/maintainer/repo.gitПри этом перед клонированием или получением изменений из официальной базы кода пользователь должен будет указать действительный пароль.
Работа в ветке: внесение и отправка изменений
В локальной копии форка репозитория разработчик может редактировать код, делать коммиты изменений и создавать ветки так же, как и в других рабочих процессах Git:
git checkout -b some-feature # Edit some code git commit -a -m "Add first draft of some feature"Все изменения будут полностью закрытыми, пока разработчик не отправит их в свой публичный репозиторий. А если кто-то внес изменения в официальный проект, можно получить доступ к новым коммитам с помощью команды git pull:
git pull upstream mainРазработчики должны писать код в отдельной функциональной ветке, поскольку такой подход обычно приводит к ускоренному слиянию.
Выполнение пул-реквеста
Когда разработчик готов поделиться новой функцией, ему нужно сделать две вещи. Во-первых, он должен открыть другим разработчикам доступ к своему коду, поместив его в свой публичный репозиторий. Поскольку удаленное подключение origin, скорее всего, уже настроено, ему остается только выполнить следующую команду:
git push origin feature-branchВ отличие от других рабочих процессов, здесь удаленное подключение origin указывает на личный репозиторий разработчика на сервере, а не на основную базу кода.
Во-вторых, разработчик должен сообщить пользователю, ответственному за поддержку проекта, что он хочет выполнить слияние функции с официальной базой кода. В Bitbucket имеется кнопка запроса pull, при нажатии которой появляется форма, в которой нужно указать ветку для ее слияния с официальным репозиторием. Как правило, разработчику нужно интегрировать свою функциональную ветку в главную ветку вышестоящего (upstream) удаленного репозитория.
Резюме
Напомним, что рабочий процесс с форками обычно используется в публичных проектах с открытым исходным кодом. Форк создают с помощью операции git clone с участием серверной копии репозитория проекта. Рабочий процесс с форками часто используется в сочетании с сервисом размещения Git, например Bitbucket. Вот общий пример рабочего процесса с форками:
1. Вы хотите включить свой код в библиотеку с открытым исходным кодом, размещенную по адресу bitbucket.org/userA/open-project
2. С помощью Bitbucket вы создаете форк репозитория по адресу bitbucket.org/YourName/open-project
3. В локальной системе вы выполняете команду git clone для https://bitbucket.org/YourName/open-project, чтобы получить локальную копию репозитория
4. Вы создаете новую функциональную ветку в локальном репозитории
5. Вы создаете новую функцию и выполняете команду git commit для сохранения изменений
6. Затем вы отправляете новую функциональную ветку в свой удаленный форк репозитория
7. С помощью Bitbucket вы открываете запрос pull для слияния новой ветки с исходным репозиторием по адресу bitbucket.org/userA/open-project
Рабочий процесс с форками помогает пользователю, ответственному за поддержку проекта, открыть репозиторий и начать принимать код от любых разработчиков. При этом ему не приходится вручную управлять настройками авторизации каждого отдельного автора. Он использует рабочий процесс в стиле pull. Чаще всего рабочий процесс с форками используется в проектах с открытым исходным кодом, однако его можно применять и в рабочих процессах частного бизнеса, чтобы обеспечить строгий контроль над слиянием с веткой релиза. Он может быть полезен командам, которые используют диспетчеры развертывания или имеют четкие циклы релизов.
Не знаете, какой рабочий процесс вам подходит? Ознакомьтесь с нашей подробной страницей сравнения рабочих процессов Git.
Поделитесь этой статьей
Следующая тема
Рекомендуемые статьи
Добавьте эти ресурсы в закладки, чтобы изучить типы команд DevOps или получать регулярные обновления по DevOps в Atlassian.
Блог Bitbucket
Образовательные программы DevOps
