Часто задаваемые вопросы о Git

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

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

Как легко скачать удаленную ветвь в локальный репозиторий?

Сначала убедитесь, что у вас настроен репозиторий origin . Если вы клонировали репозиторий с помощью git clone. При извлечении ветви, которая не существует локально, Git проверяет, есть ли удаленная ветвь с тем же именем. Если есть, Git создает локальную ветвь, которая ссылается на удаленную ветвь. Используется git pull для скачивания фиксаций и обновления журнала ветвей локально.

Как узнать, в какой ветви я работаю?

Запустите git branch без аргументов, чтобы отобразить локальные ветви и выделить извлеченную. В Visual Studio строка состояния также отображает текущую ветвь при работе с проектом, хранящимся в локальном репозитории Git.

Когда нужно сделать фиксации Git?

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

Если каждая ветвь сохраняет свою полную историю фиксации, это не делает историю фиксации *main* трудно следовать с течением времени?

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

Как узнать, кто сделал определенное изменение в файл?

git blame Используйте команду, чтобы узнать, кто внес определенное изменение в файл. В локальном репозитории можно запустить git blame с параметром -L , указав интересующие строки. Blame создает форматированные выходные данные, показывающие фиксацию, которая в последний раз обновила строку и имя пользователя, который сделал фиксацию.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame выполняет поиск журнала фиксаций для вас. Вы также можете просмотреть журнал файла на веб-портале, чтобы определить, кто сделал изменение и когда. Откройте обозреватель кода для репозитория и ветви, а затем выберите нужный файл. В Azure Repos показан полный журнал фиксаций для этого файла в текущей ветви.

Я внесли изменения в некоторые файлы, и теперь я не могу проверить другую ветвь или перебазировать мою работу.

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

Запрос на вытягивание не может объединиться с этим сообщением: "Не удается выполнить автоматическое слияние: один из внутренних объектов Git (BLOB-объектов, дерева, фиксации или тега) слишком велик, что вызвало исключение TF401022. Вы можете попытаться использовать LFS, разделить слияние или большую фиксацию на несколько небольших.

Эта проблема связана с конфликт слияния в больших двоичных файлах. Текущее ограничение для файлов составляет 100 МБ. Обходной путь — разрешить конфликт слияния локально путем объединения целевого объекта в источник локально, разрешения конфликтов и отправки изменений.

Git LFS (хранилище больших файлов) рекомендуется хранить большие двоичные файлы, не только чтобы избежать конфликтов, но и управлять общим размером репозитория, который влияет на клонирование и время отправки.

Я сделал некоторую работу, но нужно переключиться на что-то другое. Как сохранить работу позже без фиксации изменений?

Если вы хотите сохранить изменения без фиксации, используйте Git stash. Stash сохраняет текущие промежуточные и незамеченные изменения в ветви и возвращает ветвь состояние последней фиксации. Затем можно переключиться на другую ветвь, выполнить работу и позже выполнить восстановление stash apply изменений.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

При выполнении [git stash apply]последние изменения будут применены к текущей ветви. При возникновении конфликта [stash] восстанавливает изменения файлов, которые не конфликтуют и создают маркеры конфликтов в файлах, которые делают. В этом случае изменения следует объединить вручную.

После завершения работы с тайной, удалите ее с помощью [git stash drop]. Эта команда удаляет последний набор защищенных изменений.

У вас может быть несколько талей, но управление ими требует больше ручной манипуляции, так как необходимо явно применять и удалять таймы. Дополнительные сведения см. в документации по Git Stash.

Как изменить редактор по умолчанию для средств командной строки Git?

По умолчанию командная строка Git использует редактор командной строки при запросе сообщений о фиксации, выполнении перебазирования и других работах, требующих выполнения дополнительных сведений. Редактор по умолчанию настроен с помощью git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Git For Windows упрощает настройку блокнота в качестве редактора:

> git config core.editor notepad

Эта команда настраивает Блокнот Windows для редактирования сведений Git по мере необходимости и правильной передачи текста из Git в Блокнот. Можно также указать

> git config format.commitMessageColumns 72 

Чтобы сохранить текстовые столбцы в сообщениях фиксации, предпочтительный 72 и оболочку строки после нажатия этого ограничения символа в строке.

Как изменить имя пользователя и сообщение электронной почты, отображаемые в моих фиксациях?

Git помещает имя пользователя и адреса электронной почты в каждую фиксацию, а Azure Repos использует эти сведения при просмотре фиксаций и при работе с запросами на вытягивание. Если вы работаете в командной строке, вы можете обновить имя и сведения электронной почты, отображаемые git config с помощью команды:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

Параметр --global задает адрес электронной почты и имя, включенные в фиксации для всех репозиториев Git в этой системе. Если вы хотите изменить параметры для одного репозитория, необходимо изменить каталог, в котором находится репозиторий Git, и выполнить приведенные выше команды без флага --global .

Вы также можете изменить имя и параметры электронной почты из Visual Studio. В меню Git выберите "Параметры" в диалоговом окне "Параметры" выберите "Глобальные параметры Git" или "Общие параметры>репозитория Git".

Visual Studio 2019 версии 16.8 и более поздних версий предоставляет интерфейс управления версиями Git при сохранении пользовательского интерфейса Team Explorer Git. Чтобы использовать Team Explorer, снимите флажок ">Параметры>предварительного просмотра возможностей>Git" в строке меню. Вы можете выполнять функции Git из любого интерфейса взаимозаменяемо.

В Team Explorer выберите "Параметры " и в разделе Git выберите ссылку "Глобальные параметры " или "Параметры репозитория".