Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описываются основные понятия Git и процесс интеграции Git с вашей рабочей областью Microsoft Fabric.
Разрешения
- Администратор вашей организации должен включить интеграцию Git.
- Администратор клиента должен включить экспорт между географическими регионами, если рабочая область и репозиторий Azure находятся в двух разных регионах. Это ограничение не применяется к GitHub.
- Разрешения, которые у вас есть как в рабочей области, так и в Git, как указано в следующих разделах, определяют действия, которые можно предпринять.
Необходимые разрешения Git для популярных действий
В следующем списке показано, что могут делать разные роли в рабочем пространстве в зависимости от их разрешений в Git-репозитории.
- Администратор. Может выполнять любую операцию в рабочей области, ограниченную только их ролью Git.
- Участник/Вкладчик: После подключения к рабочей области участник или вкладчик может зафиксировать и обновить изменения в зависимости от роли Git. Для действий, связанных с подключением к рабочей области (например, подключение, отключение или переключение ветвей), обратитесь за помощью к администратору.
- Средство просмотра: Невозможно выполнить никакие действия. Средство просмотра не может видеть связанные с Git сведения в рабочей области.
Необходимые разрешения Fabric для основных действий
Роли рабочего пространства
В следующей таблице описаны разрешения, необходимые в рабочей области Fabric для выполнения различных распространенных операций:
| Операция | Роль рабочей области |
|---|---|
| Подключение рабочей области к репозиторию Git | Админ |
| Синхронизация рабочей области с репозиторием Git | Админ |
| Отключение рабочей области от репозитория Git | Админ |
| Переключите ветвь в рабочей области (или измените настройки подключения) | Админ |
| Просмотр сведений о подключении Git | Администратор, член, участник |
| Просмотр состояния рабочей области Git | Администратор, член, участник |
| Обновление из Git | Все следующие роли: Участник рабочей области (разрешение WRITE для всех элементов) Владелец объекта (если переключатель арендатора блокирует обновления для невладельцев) Сборка на внешних зависимостях (где применимо) |
| Фиксация изменений рабочей области в Git | Все следующие роли: Участник рабочей области (разрешение WRITE для всех элементов) Владелец объекта (если переключатель арендатора блокирует обновления для невладельцев) Сборка на внешних зависимостях (где применимо) |
| Создание новой ветви Git из Fabric | Админ |
| Перейти в другое рабочее пространство | Администратор, член, участник |
Роли Git
В следующей таблице описаны разрешения Git, необходимые для выполнения различных распространенных операций:
| Операция | Разрешения Git |
|---|---|
| Подключение рабочей области к репозиторию Git | Чтение=Разрешить |
| Синхронизация рабочей области с репозиторием Git | Чтение=Разрешить |
| Отключение рабочей области от репозитория Git | Разрешения не требуются |
| Переключите ветвь в рабочей области (или измените настройки подключения) | Чтение=Разрешено (в целевом репозитории/каталоге/ветке) |
| Просмотр сведений о подключении Git | Читать или совсем не читать |
| Просмотр состояния рабочей области Git | Чтение=Разрешить |
| Обновление из Git | Чтение=Разрешить |
| Фиксация изменений рабочей области в Git | Чтение=Разрешить Внести вклад=Разрешить Политика ветви должна разрешать прямой коммит |
| Создание новой ветви Git из Fabric | Роль=Запись Создать ветку=Разрешить |
| Перейти в другое рабочее пространство | Чтение=Разрешить Создать ветку=Разрешить |
Подключение и синхронизация
Только администратор рабочей области может подключить рабочую область к Repos Git, но после подключения любой пользователь с разрешениями может работать в рабочей области. Если вы не являетесь администратором, обратитесь к администратору за помощью к подключению.
При подключении рабочей области к Git Fabric синхронизирует содержимое между двумя расположениями, чтобы оно было одинаковым. При первоначальной синхронизации, если рабочая область или ветвь Git пуста, а другая содержит данные, содержимое копируется из непустой области в пустую. Если в рабочей области и ветви Git есть содержимое, необходимо решить, в каком направлении должна идти синхронизация.
- При зафиксировании вашей рабочей области в ветви Git, всё поддерживаемое содержимое рабочей области экспортируется в Git и перезаписывает текущее содержимое Git.
- При обновлении рабочей области с содержимым Git содержимое рабочей области перезаписывается и вы теряете содержимое рабочей области. Так как ветвь Git всегда может быть восстановлена до предыдущего состояния, а рабочая область не может, вам будет предложено подтвердить, если вы выберете этот вариант.
Если вы не выбираете, какое содержимое нужно синхронизировать, вы не сможете продолжить работу.
Папки
При подключении и синхронизации структура рабочей области зеркально отображается в репозитории Git, включая структуру папок. Элементы рабочей области в папках экспортируются в папки с тем же именем в репозитории Git. И наоборот, элементы в папках Git импортируются в папки с тем же именем в рабочей области.
Примечание.
Так как структура папок сохраняется, если у рабочей области есть папки и подключенная папка Git еще не содержит вложенных папок, они считаются разными. Вы видите статус не зафиксированные изменения в панели управления исходного кода, и необходимо зафиксировать изменения в Git перед обновлением рабочей области. При первом обновлении структура папок Git перезаписывает структуру папок рабочей области. Дополнительные сведения см. в разделе Обработка изменений папки безопасно.
- Пустые папки не копируются в Git. При создании или перемещении элементов в папку папка создается в Git.
- Пустые папки в Git удаляются автоматически.
- Пустые папки в рабочей области не удаляются автоматически, даже если все элементы перемещаются в разные папки.
- Структура папок сохраняется до 10 уровней.
Безопасная обработка изменений в папках
Если у рабочей области есть папки и подключенная папка Git еще не содержит вложенных папок, они считаются разными, так как структура папок отличается. При подключении рабочей области с папками к Git в панели управления исходным кодом вы получите статус не зафиксированы, и вам необходимо зафиксировать изменения в репозитории Git перед обновлением рабочей области.
Если вы не можете вносить изменения в подключенную ветвь напрямую из-за политики ветви или разрешений, рекомендуется использовать параметр Checkout Branch:
- Создайте новую ветвь: используйте функцию создания ветви, чтобы создать ветвь с обновленным состоянием рабочей области Fabric.
- Фиксация изменений папок: любые изменения в папке рабочей области можно зафиксировать в этой новой ветви.
- Слияние изменений: используйте ваши стандартные запросы на слияние (PR) и процедуры слияния, чтобы интегрировать эти обновления обратно в исходную ветку.
Подключение к общей рабочей области
При попытке подключиться к рабочей области, которая уже подключена к Git, может появиться следующее сообщение:
Перейдите на вкладку Accounts справа в панели управления исходным кодом, выберите учетную запись и подключитесь к ней.
Состояние Git
После подключения рабочая область отображает столбец состояния Git, указывающий состояние синхронизации каждого элемента в рабочей области относительно элементов в удаленной ветви.
Каждый элемент имеет одно из следующих состояний:
-
Синхронизирован (элемент одинаков и в рабочей области, и в ветке Git) -
Конфликт (элемент был изменен как в рабочей области, так и в ветви Git) -
Неподдерживаемый элемент -
Незафиксированные изменения в рабочем пространстве -
Обновление, необходимое для Git -
Элемент идентичен в обоих местах, но его необходимо обновить до последнего коммита.
Сведения о синхронизации
Если вы подключены, в нижней части экрана отображаются следующие сведения:
- Подключенная ветвь
- Время последней синхронизации
- Ссылка на последний коммит, с которым синхронизирована рабочая область.
Область управления исходным кодом
В верхней части экрана находится значок управления исходниками. В нем отображается количество элементов, которые отличаются в рабочей области и в ветке Git. При внесении изменений в рабочую область или ветвь Git номер обновляется. При синхронизации рабочей области с ветвью Git значок контроля версий отображает 0.
Выберите значок управления исходным кодом, чтобы открыть панель управления исходным кодом.
Панель управления исходным кодом имеет три вкладки сбоку.
Коммиты и обновления
При внесении изменений в рабочую область или ветвь Git значок системы контроля версий показывает количество элементов, которые отличаются. Выберите значок системы контроля версий, чтобы открыть панель управления системой контроля версий.
Панель коммита и обновления содержит два раздела.
Изменения показывают количество измененных элементов в рабочей области и должны быть зафиксированы в Git. Обновления показывают количество элементов, которые были изменены в ветви Git и должны быть обновлены в рабочей области.
В каждом разделе измененные элементы отображаются со значком, указывающим состояние:
-
новый -
модифицировано -
удалено -
конфликт -
те же изменения
Кнопка
"Обновить" в верхней части панели обновляет список изменений и обновлений.
фиксировать изменения
- Элементы в рабочей области, которые были изменены, перечислены в разделе "Изменения ". При наличии более чем одного измененного элемента, вы можете выбрать, какие элементы зафиксировать в ветку Git.
- Если в ветви Git были сделаны обновления, коммиты будут недоступны, пока не обновите рабочую область.
Обновить
- В отличие от коммита и отката, команда Update всегда обновляет всю ветвь и синхронизируется с последним коммитом. Не удается выбрать определенные элементы для обновления.
- Если изменения были внесены в рабочую область и в ветви Git на том же элементе, обновления отключаются до устранения конфликта.
Узнайте больше о том, как зафиксировать изменения и обновить. Узнайте больше о процессе обновления и о том, как устранить конфликты.
Филиалы
Вкладка Branches панели управления исходным кодом позволяет управлять ветвями и выполнять связанные с ними действия. В нем есть два основных раздела:
Действия, которые можно выполнить в текущей ветви:
Разветвление в другую рабочую область (участник и выше): создает новую рабочую область или переключается на существующую рабочую область в зависимости от последнего коммита в текущей рабочей области. Затем он подключается к целевой рабочей области и ветке.
Проверка новой ветки (требуется быть администратором рабочей области): создает новую ветку на основе последнего синхронизированного коммита в рабочей области и изменяет подключение Git в текущей рабочей области. Он не изменяет содержимое рабочей области.
Смена ветки (необходимы права администратора): синхронизирует рабочую область с другой новой или существующей веткой и заменяет все элементы в рабочей области содержимым выбранной ветки.
- Связанные ветви. На вкладке "Ветви" также есть список связанных рабочих областей, на которые можно выбрать и переключиться. Связанная рабочая область — это одна с теми же свойствами подключения, что и текущая ветвь, например та же организация, project, репозиторий и папка git. Эта функция позволяет переходить к рабочим областям, подключенным к другим ветвям, связанным с контекстом текущей работы, без необходимости искать их в списке рабочих областей Fabric. Чтобы открыть соответствующую рабочую область, выберите элемент в списке.
Дополнительные сведения см. в разделе Ограничения ветвления.
Сведения об учетной записи
На вкладке сведений об учетной записи отображаются сведения о учетной записи GitHub, к которому подключен пользователь. В нем есть два раздела. В верхнем разделе показаны поставщик Git и имя учетной записи. В нижнем разделе показаны репозиторий и ветвь, к которым подключена рабочая область. В настоящее время эта вкладка доступна только для рабочих областей, подключенных к GitHub.
Детали учетной записи GitHub:
Сведения о учетной записи Git
Поставщик
Имя учетной записи
Репозиторий Git
Отрасль
Рекомендации и ограничения
Общие ограничения интеграции Git
- Метод проверки подлинности в Fabric должен быть не менее строгим, чем метод проверки подлинности для Git. Например, если Git требует многофакторной проверки подлинности, Структура должна также требовать многофакторную проверку подлинности.
- В настоящее время наборы данных Power BI, подключенные к службам Analysis Services, не поддерживаются.
- Если вы используете идентификатор рабочей области в одном артефакте и фиксируете его в Git, его можно обновить обратно в рабочую область fabric только в той рабочей области, которая подключена к тому же идентификатору. Будьте осторожны, так как это также влияет на такие функции, как разветвление.
- Подмодулы не поддерживаются.
- Независимые облака не поддерживаются.
- Если рабочая область содержит сотни элементов, попробуйте разделить ее на небольшие наборы артефактов. Каждый набор должен быть помещен в отдельную рабочую область и связан с другой ветвью Git или подключен к одной ветви, упорядоченной в разные папки.
- Ограничения Azure DevOps
- ограничения GitHub
- Azure DevOps не поддерживается, если включена проверка политики обнаружения IP-адрессов условного доступа.
- Если рабочая область и репозиторий Git находятся в двух разных географических регионах, администратор клиента должен включить межрегиографный экспорт.
- Если ваша организация настроила условный доступ, убедитесь, что Power BI Service имеет тот же набор условий, чтобы проверка подлинности выполнялась как ожидается.
- Применяется следующее ограничение размера коммита:
- 25 МБ с помощью соединителя Azure DevOps с учетной записью службы.
- 125 МБ с использованием учетной записи единого входа по умолчанию Microsoft Entra ID и с Azure DevOps-коннектором с основным пользователем.
ограничения GitHub Enterprise
Некоторые версии и параметры enterprise GitHub не поддерживаются. Например:
- GitHub Enterprise Server с настраиваемым доменом не поддерживается, даже если экземпляр имеет публичный доступ.
- GitHub Enterprise Server, размещенный в частной сети
- Список разрешенных IP-адресов
Рассмотрение миграции с Azure DevOps на GitHub Enterprise
Если ваша команда использует интеграцию Fabric Git и оценивает миграцию из Azure DevOps в GitHub Enterprise, рекомендуется выполнить тесты валидации, чтобы обеспечить, что функциональность интеграции Git осталась неизменной. Интеграция Git Fabric использует базовые API поставщика Git, которые отличаются возможностями и ограничениями между Azure DevOps и GitHub Enterprise, как описано выше.
Различия между поведением Git Integration и восстановлением элементов корзины
При использовании интеграции Git может возникнуть непредвиденное поведение в сценариях, когда удаленные элементы создаются повторно или восстанавливаются с помощью сочетания операций Git и восстановления корзины. Это происходит потому, что операции Git (например, отмена или обновление из Git) повторно создают удаленные элементы путем назначения нового идентификатора элемента, а восстановление элемента из корзины сохраняет исходный идентификатор элемента. В результате в рабочей области могут существовать повторяющиеся элементы с разными идентификаторами, что может привести к прекращению работы интеграции Git и также повлиять на существующие зависимости.
Смягчение последствий
Удалите элемент, который был повторно создан интеграцией Git. После удаления повторяющегося элемента операции Git должны возобновиться нормально.
Дополнительные заметки
Интеграция Git повторно создает определения элементов только и не восстанавливает данные элементов. В отличие от этого, восстановление элемента из корзины восстанавливает определение элемента и его данные.
Сведения о различиях в конвейере развертывания см. в нашей документации.
Ограничения рабочей области
- Только администратор рабочей области может управлять подключениями к репозиторию Git Repo таким как подключение, отключение или добавление ветви.
После подключения любой пользователь с разрешением может работать в рабочей области. - Рабочие области с установленными приложениями-шаблонами не могут быть подключены к Git.
- MyWorkspace не может подключиться к поставщику Git.
- Рабочие области могут содержать не более 1000 элементов. Если ветвь Git содержит более 1000 элементов, синхронизация содержимого с рабочей областью завершится ошибкой. Чтобы избежать этого ограничения, рассмотрите возможность разделения артефактов на небольшие наборы. Каждый набор должен быть помещен в отдельную рабочую область и связан с другой ветвью Git или организован в разные папки в одной ветви. Для дальнейшего чтения ознакомьтесь с ограничениями элемента рабочей области.
Ограничения ветвей и папок
- Максимальная длина имени ветви составляет 244 символа.
- Максимальная длина полного пути для имен файлов составляет 250 символов. Длинные имена не работают.
- Максимальный размер файла составляет 25 МБ.
- Структура папок поддерживается до 10 уровней.
- Скачивание отчета или набора данных в виде PBIX из службы после их развертывания с интеграцией Git не рекомендуется, так как результаты ненадежны. Мы рекомендуем использовать Power BI Desktop для скачивания отчетов и наборов данных в виде PBIX.
- Если отображаемое имя элемента имеет какие-либо из этих характеристик, папка Git переименовывается в логический идентификатор (GUID) и тип.
- При подключении рабочей области с папками к Git необходимо зафиксировать изменения в репозитории Git, если эта структура папок отличается.
Ограничения имени каталога
Имя каталога, подключающегося к репозиторию Git, имеет следующие ограничения именования:
- Имя каталога не может начинаться или заканчиваться пробелом или вкладкой.
- Имя каталога не может содержать ни одного из следующих символов: "/:<>\*?|
Папка элемента (папка, содержащая файлы элементов), не может содержать ни одного из следующих символов: ":<>\*?|". Если вы переименовываете папку в одну из этих символов, Git не может подключиться или синхронизироваться с рабочей областью и возникает ошибка.
Ограничения процесса разветвления
- Для ответвления требуются разрешения, перечисленные в таблице разрешений.
- Для этого действия должны быть доступные возможности.
- Все ограничения именования рабочих областей и ветвей применяются при разветвлении в новую рабочую область.
- В новой рабочей области доступны только элементы, поддерживаемые Git.
- В списке связанных ветвей отображаются только ветви и рабочие области, которые у вас есть разрешение на просмотр.
- Интеграция Git должна быть включена.
- При выходе из ветвления создается новая ветвь, а параметры исходной ветви не копируются. Настройте все параметры или определения, чтобы обеспечить соответствие новым политикам вашей организации.
- При создании ответвления от существующего рабочего пространства:
- Целевая рабочая область должна поддерживать подключение Git.
- Пользователь должен быть администратором целевой рабочей области.
- Целевая рабочая область должна иметь необходимую вместимость.
- Рабочая область не может иметь приложения-шаблоны.
- Обратите внимание, что при выходе из рабочей области все элементы, которые не сохраняются в Git, могут быть потеряны. Мы рекомендуем зафиксировать все элементы, которые вы хотите сохранить перед ветвлением.
Ограничения синхронизации и коммита
- Одновременно можно синхронизировать только в одном направлении. Вы не можете одновременно зафиксировать и обновить.
- Метки конфиденциальности не поддерживаются, и экспорт элементов с метками конфиденциальности может быть отключен. Чтобы зафиксировать элементы, имеющие метки конфиденциальности, без применения этих меток, обратитесь к своему администратору за помощью.
- Работает с ограниченными элементами. Неподдерживаемые элементы в папке игнорируются.
- Дублирование имен не допускается. Даже если Power BI позволяет дублирование имен, обновление, фиксация или отмена операции не удается.
- B2B не поддерживается.
- Разрешение конфликтов частично выполняется в Git.
- Во время процесса фиксации в Git сервис Fabric удаляет файлы внутри папки элемента, которые не входят в определение элемента. Не связанные файлы, не входящие в папку элемента, не удаляются.
- После применения изменений вы можете заметить некоторые непредвиденные изменения в элементе, которые вы не вносили. Эти изменения семантически незначительны и могут произойти по нескольким причинам. Например:
- Изменение файла определения элемента вручную. Эти изменения допустимы, но могут отличаться от того, что сделано через редакторы. Например, если вы переименовываете столбец семантической модели в Git и импортируете это изменение в рабочую область, при следующей фиксации изменений в семантической модели файл bim будет регистрироваться как измененный, и измененный столбец будет перемещен в конец массива
columns. Это связано с тем, что подсистема AS, создающая файлы bim , отправляет переименованные столбцы в конец массива. Это изменение не влияет на способ работы элемента. - Совершение файла, использующего разрывы строк CRLF. Служба использует LF (подача строки) для разрыва строк. Если у вас есть файлы в репозитории Git с разрывами строк CRLF, при фиксации через службу эти файлы меняются на LF. Например, если открыть отчет на рабочем столе, сохраните файл project (.pbip) и отправьте его в Git с помощью CRLF.
- Изменение файла определения элемента вручную. Эти изменения допустимы, но могут отличаться от того, что сделано через редакторы. Например, если вы переименовываете столбец семантической модели в Git и импортируете это изменение в рабочую область, при следующей фиксации изменений в семантической модели файл bim будет регистрироваться как измененный, и измененный столбец будет перемещен в конец массива
- Обновление семантической модели с помощью API расширенного обновления вызывает дифф Git после каждого обновления.