Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Visual Studio 2019 | Visual Studio 2022
Git репозитории полезны, если нужно вносить экспериментальные, рискованные или скрытые изменения в кодовую базу, но те изменения следует изолировать от исходного репозитория. Новая ветка — это новый удаленный репозиторий, который использует исходный код оригинального репозитория.
Как независимая копия, изменения, внесенные в ваше ответвление, например добавление коммитов или веток, скрыты от оригинального репозитория. Если вы хотите объединить изменения в кодовой базе в исходный репозиторий, необходимо создать pull request (PR), чтобы запросить проверку и утверждение этих изменений.
Процесс форка не передает разрешения, политики или цепочки сборки из исходного репозитория в ваш форк.
В этой статье рассматривается работа с форками в репозиториях Git в Azure Repos, а также приводятся ссылки на материалы GitHub, описывающие управление форками в репозиториях GitHub.
В этой статье раскрываются следующие темы:
- совместно использовать код в ответвлениях.
- осуществлять выбор между ветвями и вилками;
- Включение форков репозитория
- Создать форк
- Клонируйте ваш форк локально
- Отправка локальных изменений в форк
- Создать и завершить пулл-реквест
- Синхронизируйте ваш форк
Предпосылки
| Категория | Требования |
|---|---|
| доступ к проекту | Член проекта . |
| Разрешения | — Просмотр кода в частных проектах: по крайней мере базовый доступ. — Клонирование или внесение вклада в код в частных проектах: Участник группы безопасности для участников или наличие соответствующих разрешений в проекте. — Задайте разрешения ветви или репозитория: управление разрешениями для ветви или репозитория. — Измените ветвь по умолчанию: . Измените политики и разрешения для репозитория. — Импорт репозитория: член группы безопасности администраторов проекта или разрешение уровня проекта Git на создание репозитория установлено в «Разрешить» . Дополнительные сведения см. в разделе "Настройка разрешений репозитория Git". |
| услуги | Repos включено. |
| Инструменты | Необязательно. Используйте команды az repos: Azure DevOps CLI. |
Примечание.
В общедоступных проектах пользователи с доступом Stakeholder имеют полный доступ к Azure Repos, включая возможность просмотра, клонирования и участия в коде.
| Категория | Требования |
|---|---|
| доступ к проекту | Член проекта . |
| Разрешения | — Просмотр кода: доступ уровня Basic хотя бы . — Клонирование или участие в коде: член группы безопасности участников или обладатель соответствующих разрешений в проекте. |
| услуги | Repos включено. |
совместное использование кода в форках.
Исходный репозиторий часто называется вышестоящим репозиторием. Вы можете создавать pull requests для слияния изменений в любом направлении: из fork в основной репозиторий или из основного репозитория в fork. Наиболее распространенное направление — от форка к основному проекту. Разрешения, политики, сборки и рабочие элементы целевого репозитория будут применены к PR.
осуществлять выбор между ветвями и вилками;
Для небольшой команды из 2–5 разработчиков рабочий процесс вилки может быть не нужен, так как все могут работать в ветках функций, а политика веток может защитить ветку по умолчанию. Тем не менее, если ваша команда расширяется и перерастает данную структуру, они могут переключиться на форковый рабочий процесс.
Если в вашем репозитории много одноразовых или нерегулярных участников, как в проекте с открытым исходным кодом, рекомендуется использовать форкинг рабочий процесс. Как правило, только ключевые участники проекта должны иметь прямые права на внесение коммитов в исходный репозиторий. Другие участники должны использовать схему работы с форками для изоляции своих предложений по изменениям до тех пор, пока основные участники не смогут их просмотреть.
Включение форков репозитория
Чтобы включить форки для репозитория Azure Repos Git, см. включение форков.
Чтобы включить форки для репозитория GitHub, см. "Управление политикой форков для вашей организации".
Рабочий процесс форка
Рабочий процесс форка состоит из пяти шагов, описанных в следующих разделах.
- Создать форк
- Клонируйте ваш форк локально
- Отправьте локальные изменения в форк
- Сделать и завершить PR
- Синхронизируйте свой форк
Создать форк
Ниже описано, как форкать репозиторий Git в Azure Repos.
Примечание.
Чтобы форкнуть репозиторий в проекте Azure DevOps, необходимо иметь разрешение создать репозиторий для этого проекта. Владельцы репозитория должны рассмотреть возможность создания отдельного проекта для форков и назначении разрешения на создание репозитория всем участникам. Дополнительные сведения о настройке разрешений см. в разделе "Настройка разрешений репозитория Git".
В веб-браузере перейдите в репозиторий Git в Azure Repos, который вы хотите форкнуть. Выберите Файлы репозитория и затем выберите Вилка в меню с многоточием, чтобы открыть диалоговое окно Вилка.
В диалоговом окне Fork назовите форк репозитория, выберите проект, в котором нужно создать форк, выберите ветви, которые нужно включить в форк, а затем нажмите Fork. Можно указать, будет ли вилка содержать все ветви или только ветвь по умолчанию. Если репозиторий содержит несколько тематических веток, рассмотрите включение только ветки по умолчанию в форк.
Сведения о том, как создать репозиторий GitHub, см. в разделе Fork a repo.
Клонируйте ваш форк локально
После того, как вы сделали форк репозитория, клонируйте его, чтобы создать локальную копию в папке на вашем компьютере. Вы можете клонировать из командной строки или с помощью интегрированной среды разработки, например Visual Studio. Дополнительные сведения о клонировании репозитория см. в разделе Клонирование существующего репозитория Git.
При клонировании удаленного репозитория Git назначает псевдоним origin как сокращенный URL-адрес клонированного удаленного репозитория. Для удобства добавьте еще один псевдоним с именем upstream для репозитория, из которого вы сделали форк, называемого основным репозиторием. Ниже описано, как добавить upstream псевдоним.
Совет
Для удобства в командах Git можно использовать псевдонимы origin и upstream вместо их соответствующих URL-адресов.
Чтобы добавить upstream псевдоним в Visual Studio, выполните следующие действия.
Выберите Инструменты > Параметры в строке меню, чтобы открыть окно Параметры. Выберите "Управление исходным кодом > Параметры репозитория Git > Удалённые" и затем нажмите "Добавить", чтобы открыть диалоговое окно "Добавить удалённый".
В диалоговом окне "Добавление удаленного" добавьте новый удаленный репозиторий
upstreamи введите URL-адрес клона Git для форкнутого репозитория. Затем нажмите кнопку "Сохранить".
Отправьте локальные изменения в форк
Когда вы делаете форк, вы создаёте личную версию исходного репозитория (исходный репозиторий называется "upstream"). Форк независим от изначального проекта, но форк делится кодом и сохраняет ссылку на изначальному проекту, что позволяет выполнять дальнейшую синхронизацию. Таким образом, ничто не мешает вам работать непосредственно в ветке main локального клона, а затем отправить эту работу в ветку main вашего форка. Однако, как правило, лучше использовать ветвь компонента для вашей работы. С помощью функциональных веток:
Одновременно можно поддерживать несколько независимых рабочих потоков.
Вы упрощаете другим понимание вашей работы, поскольку она организована в отдельные рабочие потоки по каждому направлению.
Типичный рабочий процесс Git включает следующие действия:
Создайте локальную функцию или ветвь исправления ошибок.
Внесите изменения в новую ветку и зафиксируйте свою работу. Как правило, при работе над функцией или исправлением ошибок люди делают несколько коммитов.
Отправьте ветку функции или исправления ошибок в ваш форк. У вашей вилки есть псевдоним
origin.
Сведения о отправке изменений см. в статье "Общий доступ к коду с помощью push-отправки".
Создание и завершение пулл реквеста
В Azure Repos вы можете объединить изменения в исходный репозиторий, которые были отправлены в ваш форк.
Создайте PR для запроса на проверку и утверждение ваших изменений. Когда вы открываете PR, укажите в качестве исходной ветки PR функциональную ветку или ветку исправлений в вашем форке. Обычно целевая ветвь PR — это
main, ветвь репозитория, который вы форкнули. Этот репозиторий называется вышестоящим репозиторием и имеет псевдонимupstream.На следующем снимке экрана показаны репозиторий и ветвь исходного и репозиторий и ветвь целевого PR, созданного в Azure Repos.
Дополнительные сведения о создании PR с помощью браузера, Visual Studio или Azure DevOps CLI см. в статье "Создание PR".
Внимание
Любой пользователь в группе Project Valid Users и с разрешением Чтение в вышестоящем репозитории может открыть к нему pull request. Если в вышестоящем репозитории есть сборочный конвейер для PR, настроенный для запуска при создании PR, сборка будет запущена для изменений, внесенных вашим PR.
Для завершения этого PR все необходимые рецензенты должны утвердить изменения в PR, и все политики целевой ветви должны быть выполнены. При утверждении и завершении PR изменения в исходной ветви PR сливаются с целевой ветвью PR.
Сведения о создании и завершении запроса на вытягивание см. в статье "Создание запроса на вытягивание" и объединение запроса на вытягивание.
Синхронизируйте ваш форк.
После слияния изменений из форка в целевую ветвь внешнего репозитория можно вытянуть из целевой ветви внешнего репозитория, чтобы обновить соответствующую локальную ветвь как с вашими изменениями, так и с любыми изменениями, внесенными другими участниками. Затем вы готовы:
Создайте новую функцию или ветвь исправления ошибок из обновленной локальной ветви.
Обновите fork, отправив изменения из обновленной локальной ветки в
origin.
Как правило, целевая ветвь исходного репозитория main. Если вы не редактируете локальную main ветвь напрямую (вы работаете в фича-ветках), то извлечение из вышестоящей upstream/main ветки обновит локальную main ветвь без конфликтов слияния.