Вилки

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Пакеты репозитория Git полезны, когда люди хотят вносить экспериментальные, рискованные или конфиденциальные изменения в базу кода, но эти изменения должны быть изолированы от базы кода в исходном репозитории. Новый вилку в основном является клоном исходного репозитория, отправленного в новый удаленный репозиторий. Вилка не зависит от исходного репозитория и является полной копией, если только не указана одна ветвь.

В качестве независимой копии изменения, внесенные в вилку, например добавление фиксаций или ветвей, не являются общими для исходного репозитория. Если вы хотите объединить изменения базы кода в исходный репозиторий, необходимо создать запрос на вытягивание (PR), чтобы запросить проверку и утверждение этих изменений.

Процесс вилки не передает разрешения, политики или конвейеры сборки из исходного репозитория в вилку.

В этой статье рассматриваются сведения о работе с вилками в репозиториях Git в Azure Repos, а также ссылки на содержимое GitHub, которое описывает управление вилками в репозиториях GitHub.

В этой статье раскрываются следующие темы:

• совместно использовать код в вилках.
• осуществлять выбор между ветвями и вилками;
• Включение вилок репозитория
• Создание вилки
• Клонирование вилки локально
• Отправка локальных изменений в вилку
• Создание и выполнение запроса на вытягивание
• Синхронизация вилки

Предварительные требования для доступа к Azure Repos

• Репозитории должны быть включены в параметрах проекта Azure DevOps. Если концентратор Repos и связанные страницы не отображаются, см. раздел "Включение или отключение службы Azure DevOps" для повторного использования репозиториев.

• Чтобы просмотреть код в частных проектах, необходимо быть членом проекта Azure DevOps с уровнем доступа "Базовый " или выше. Для общедоступных проектов каждый может просматривать код.

  • Если у вас нет проекта, создайте его или зарегистрируйтесь бесплатно.

  • Если вы не член проекта, добавьте его.

• Чтобы клонировать или внести свой вклад в код для частного проекта, необходимо быть членом группы безопасности участников или иметь соответствующий набор разрешений. Для общедоступных проектов любой пользователь может клонировать и внести свой вклад в код. Дополнительные сведения см. в статье "Что такое общедоступный проект"?

  Примечание.

  Для общедоступных проектов пользователи, которым предоставлен доступ заинтересованных лиц , имеют полный доступ к Azure Repos.

совместно использовать код в вилках.

Исходный репозиторий часто называется репозиторием вышестоящий. Вы можете создавать PR для слияния изменений в любом направлении: от вилки до вышестоящий или вышестоящий вилку. Наиболее распространенное направление — от вилки до вышестоящий. Разрешения целевого репозитория, политики, сборки и рабочие элементы будут применяться к pr.

осуществлять выбор между ветвями и вилками;

Для небольшой команды разработчиков из 2–5 может потребоваться рабочий процесс вилки, так как все могут работать в ветвь компонента и политиках филиалов, могут защитить ветвь по умолчанию. Тем не менее, если ваша команда расширяет и выравливает эту структуру, они могут переключиться на рабочий процесс вилки.

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

Включение вилок репозитория

Чтобы включить вилки для репозитория Azure Repos Git, см. сведения о включении вилки.

Чтобы включить вилки для репозитория GitHub, см. статью "Управление политикой вилки для вашей организации".

Рабочий процесс создания вилки

Рабочий процесс вилки состоит из пяти шагов, описанных в следующих разделах.

1. Создание вилки
2. Клонирование вилки локально
3. Отправка локальных изменений в вилку
4. Создание и завершение pr
5. Синхронизация вилки

Создание вилки

Ниже описано, как создать репозиторий Azure Repos Git.

Примечание.

Чтобы создать репозиторий в проекте Azure DevOps, необходимо иметь разрешение на создание репозитория для этого проекта. Владельцы репозитория должны рассмотреть вопрос о создании выделенного проекта для вилок и назначении разрешения на создание репозитория для всех участник. Дополнительные сведения о настройке разрешений см. в разделе "Настройка разрешений репозитория Git".

1. В веб-браузере перейдите в репозиторий Azure Repos Git, который вы хотите вилировать. Выберите "Файлы репозитория>", а затем в меню с многоточием выберите в меню с многоточием, чтобы открыть диалоговое окно "Вилка".

   

2. В диалоговом окне "Вилка" назовите вилку репозитория, выберите проект, в котором нужно создать вилку, выберите ветви, которые нужно включить в вилку, а затем выберите вилку. Можно указать, будет ли вилка содержать все ветви или только ветвь по умолчанию. Если репозиторий содержит несколько ветвей раздела, рассмотрите возможность включения только ветвь по умолчанию в вилку.

   

Сведения о том, как создать репозиторий GitHub, см. в разделе Fork a repo.

Клонирование вилки локально

После создания вилки репозитория клонируйте вилку, чтобы создать локальную копию в папке на компьютере. Вы можете клонировать из командной строки или с помощью интегрированной среды разработки, например Visual Studio. Дополнительные сведения о клонировании репозитория см. в разделе Клонирование существующего репозитория Git.

При клонировании удаленного репозитория Git назначает псевдоним origin как сокращенный URL-адрес клонированного удаленного репозитория. Для удобства добавьте еще один псевдоним с именем upstream вилки репозитория, который называется репозиторием вышестоящий. Ниже описано, как добавить upstream псевдоним.

Совет

Для удобства можно использовать origin псевдонимы вместо upstream соответствующих URL-адресов в командах Git.

Visual Studio

Чтобы добавить upstream псевдоним в Visual Studio, выполните следующие действия.

1. Выберите "Параметры инструментов>" в строке меню, чтобы открыть окно "Параметры". Выберите репозиторий Git для управления > версиями Параметры > remotes, а затем нажмите кнопку "Добавить", чтобы открыть диалоговое окно "Добавить удаленный".

   

2. В диалоговом окне "Добавление удаленного" добавьте новый удаленный вызов upstream и введите URL-адрес клона Git для вилки репозитория. Затем нажмите кнопку "Сохранить".

   

Командная строка

В командной строке перейдите в корневую папку локального репозитория, а затем выполните следующую команду, чтобы добавить новое удаленное имя upstream. Замените <clone URL> URL-адрес клона Git вилированного репозитория.

git remote add upstream <clone URL>

Например, git remote add upstream https://fiber-teams@dev.azure.com/fiber-teams/FiberTests/_git/FiberTests добавляет upstream псевдоним.

Чтобы изменить существующий upstream псевдоним, выполните следующую команду:

git remote set-url upstream <clone URL>

Отправка локальных изменений в вилку

При вводе вы создаете личную и независимую копию удаленного репозитория. Таким образом, нет ничего, чтобы предотвратить работу непосредственно в main ветви локального клона, а затем толкать эту работу в main ветвь вашего вилки. Однако, как правило, лучше использовать ветвь компонента для вашей работы. С помощью ветвь компонента:

• Одновременно можно поддерживать несколько независимых рабочих потоков.

• Для других пользователей проще понять общую работу, так как эта работа организована в отдельные рабочие потоки по ветви.

Типичный рабочий процесс Git включает следующие действия:

1. Создайте локальную функцию или ветвь исправления ошибок.

2. Внесите изменения в новую ветвь и зафиксируйте свою работу. Как правило, при работе с функцией или исправлением ошибок люди делают несколько фиксаций.

3. Отправьте функцию или ветвь исправления ошибок в вилку. У вашего вилки есть псевдоним origin.

Сведения о отправке изменений см. в статье "Общий доступ к коду с помощью push-отправки".

Создание и выполнение запроса на вытягивание

В Azure Repos можно объединить в исходный репозиторий изменения, отправленные в вилку, :

1. Создайте pr для запроса проверки и утверждения изменений. Когда вы открываете PR, задайте ветвь источника PR для функции или ветвь исправлений в вилке. Целевая ветвь PR обычно main является ветвью вилки репозитория. Этот репозиторий называется репозиторием вышестоящий и имеет псевдонимupstream.

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

   

   Дополнительные сведения о создании PR с помощью браузера, Visual Studio или Azure DevOps CLI см. в статье "Создание PR".

   Внимание

   Любой пользователь с разрешением на чтение в репозитории вышестоящий может открыть к нему PR. Если в репозитории вышестоящий есть конвейер сборки PR, настроенный для запуска при создании PR, сборка будет выполняться в изменениях, введенных вашим PR.

2. Для завершения pr все необходимые рецензенты должны утвердить изменения pr и все политики целевой ветви должны быть выполнены. При утверждении и завершении pr изменения в исходной ветви pr будут объединяться в целевую ветвь PR.

Сведения о создании и завершении запроса на вытягивание см. в статье "Создание запроса на вытягивание" и объединение запроса на вытягивание.

Синхронизация вилки

После слияния изменений из вилки в целевую ветвь репозитория вышестоящий можно извлечь из целевой ветви репозитория вышестоящий, чтобы обновить соответствующую локальную ветвь как с изменениями, так и с любыми изменениями, внесенными другими участник. Затем вы готовы:

• Создайте новую функцию или ветвь исправления ошибок из обновленной локальной ветви.

• Обновите вилку путем отправки из обновленной локальной ветви originв .

Как правило, целевая ветвь репозитория вышестоящий main. Если вы не редактируете локальную main ветвь напрямую (вы работаете в ветвь компонента), то извлечение из upstream/main вышестоящая ветвь обновит локальную main ветвь без конфликт слияния.

Следующие шаги

Предоставление общего доступа к коду с запросами на вытягивание push-проверки

Связанные статьи

• Новые репозитории Git? Подробнее
• Обновление кода с получением, слиянием и извлечением
• Сохранение работы с фиксациями