Перейти к содержимому

Как поменять default ветку git

  • автор:

Изменение ветви по умолчанию

Ветвь по умолчанию — это первая ветвь, которую Git будет проверка на свежем клоне. Кроме того, запросы на вытягивание нацелены на эту ветвь по умолчанию.

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

Настройка нового ветвь по умолчанию

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

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

Для изменения ветвь по умолчанию требуется разрешение На изменение политик. Дополнительные сведения см. в разделе Настройка разрешений репозитория Git.

Снимок экрана: установка ветвь по умолчанию.

  1. В репозитории проекта выберите Ветви.
  2. На странице Ветви выберите Дополнительные параметры рядом с новым ветвь по умолчанию и выберите Задать как ветвь по умолчанию.
  3. После настройки нового ветвь по умолчанию при необходимости можно удалить предыдущее значение по умолчанию.
  1. Нажмите кнопку «Параметры» в левом нижнем углу проекта, чтобы открыть страницу администрирования проекта. Откройте административную область веб-портала для проекта.
  2. Выберите Репозитории.
  3. Выберите репозиторий Git. Ветви отображаются в репозитории.
  4. Выберите . рядом с ветвью, которую нужно задать по умолчанию, а затем выберите Задать как ветвь по умолчанию. Настройка ветвь по умолчанию для репозитория Git
  5. После настройки нового ветвь по умолчанию при необходимости можно удалить предыдущее.
  1. Нажмите кнопку «Параметры» в проекте, чтобы открыть страницу администрирования проекта. Откройте административную область веб-портала для проекта.
  2. Выберите Управление версиями.
  3. Выберите репозиторий Git. Ветви отображаются в репозитории.
  4. Выберите . рядом с ветвью, которую нужно задать по умолчанию, а затем выберите Задать как ветвь по умолчанию. Настройка ветвь по умолчанию для репозитория Git
  5. После настройки нового ветвь по умолчанию при необходимости можно удалить предыдущее.

Перед внесением этого изменения следует учитывать и другие аспекты.

Выберите имя

В Git 2.28 добавлена возможность выбора начального имени ветви. В то же время Azure Repos, GitHub и другие поставщики услуг размещения Git добавили возможность выбора другого начального имени ветви. Ранее ветвь по умолчанию почти всегда назывался master . Наиболее популярным альтернативным именем является main . Менее распространенные варианты включают trunk и development . При отсутствии ограничений в используемых вами средствах или команде будет работать любое допустимое имя ветви.

Обновление других систем

При переходе на другую ветвь по умолчанию могут быть затронуты другие части рабочего процесса. Эти части необходимо учитывать при планировании изменений.

Pipelines

Обновите триггеры CI для всех конвейеров. Designer конвейеры можно редактировать в Интернете. Конвейеры YAML можно редактировать в соответствующих репозиториях.

Запросы на вытягивание в режиме выполнения

Существующие клоны

Новые клоны репозитория получат новые ветвь по умолчанию. После переключения все пользователи с существующим клоном должны выполнить команду git remote set-head origin -a (заменив именем своего удаленного репозитория origin , если это что-то другое), чтобы обновить представление ветвь по умолчанию удаленного репозитория. Будущие новые ветви должны основываться на новом значении по умолчанию.

Входящие ссылки

Некоторые закладки, документы и другие файлы, не относящиеся к коду, которые указывают на файлы в Azure Repos, необходимо будет обновить. Имя ветви для файла или каталога может отображаться в URL-адресе.

Если URL-адрес содержит строку запроса для version , например &version=GBmybranchname , этот URL-адрес следует обновить. К счастью, большинство ссылок на ветвь по умолчанию не будут иметь version сегмента и могут быть оставлены как есть. Кроме того, после удаления старого ветвь по умолчанию попытки перейти к нему будут в любом случае переходить к новому по умолчанию.

Временное зеркальное отображение

Репозиторий Git может иметь только одну ветвь по умолчанию. Однако на некоторое время можно настроить нерегламентированное зеркальное отображение между старым и новым значением по умолчанию. Таким образом, если конечные пользователи продолжают использовать старое значение по умолчанию, им не нужно будет повторять работу. Мы будем использовать Azure Pipelines для настройки этого временного зеркального отображения.

В этом разделе используется язык, который расходится с точки зрения Майкрософт. В частности, слово master отображается в нескольких местах в соответствии с тем, как оно использовалось в Git. Цель этого раздела — объяснить, как перейти на более инклюзивный язык, например main . Избегая всех упоминание master , это усложнит понимание направлений.

Конвейер зеркального отображения

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

Если старая и новая ветви по умолчанию обновляются до выполнения этого конвейера, конвейер не сможет зеркало изменений. Кому-то придется вручную объединить старую ветвь по умолчанию в новую ветвь по умолчанию, чтобы снова запустить ее автоматически.

  1. Для всех существующих сборок CI обновите их, чтобы активировать их для новой ветвь по умолчанию вместо старой.
  2. Предоставьте удостоверению сборки разрешение Участие в репозитории. Перейдите в раздел Параметры> проектаРепозитории>(ваш репозиторий)>Разрешения. Может быть до двух удостоверений: одно для службы сборки коллекции проектов, а другое — для службы сборки проектов. Убедитесь, что для разрешения Участие указано значение Разрешить.
  1. Если новый ветвь по умолчанию имеет политики ветвей, также предоставьте удостоверению сборки политики Обхода при отправке разрешения. Это разрешение представляет угрозу безопасности, так как злоумышленник может создать конвейер, чтобы проникнуть в репозиторий в проекте. Если зеркальное отображение больше не требуется, обязательно удалите это разрешение.
  2. Добавьте новый файл mirror.yml в репозиторий в новом ветвь по умолчанию. В этом примере предполагается, что старый ветвь по умолчанию — , master а новый — main . Обновите триггерные ветви и строку, git push если имена ветвей отличаются.
trigger: branches: include: - main - master pool: < vmImage: ubuntu-latest >steps: - checkout: self persistCredentials: true - script: | git checkout $(Build.SourceBranchName) git push origin HEAD:master HEAD:main displayName: Mirror old and new default branches 
  1. Создайте новый конвейер, выбрав в мастере пункты «Azure Repos Git» и «Существующий YAML-файл Azure Pipelines». Выберите файл, mirror.yml добавленный на предыдущем шаге. Сохраните и запустите конвейер.

Устранение неполадок

Этот конвейер будет выполняться каждый раз при отправке в master или в main . Они будут синхронизированы до тех пор, пока новые фиксации не поступают в обе ветви одновременно.

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

  1. Клонируйте репозиторий и cd в его каталог.
  2. Ознакомьтесь с новым ветвь по умолчанию с git checkout main (если main это ваш новый ветвь по умолчанию).
  3. Создайте новую ветвь для интеграции двух ветвей с git checkout -b integrate .
  4. Объедините старую ветвь по умолчанию с git merge master (если master это старый ветвь по умолчанию).
  5. Отправьте новую ветвь, а затем откройте и завершите запрос на вытягивание в новую ветвь по умолчанию.
  6. Затем конвейер зеркального отображения должен выполнить зеркальное отображение фиксации слияния в старом значении по умолчанию.

Изменить ветку по умолчанию git

Забыл создать ветку по умолчанию теперь у меня ветвление идёт от ветки, которую я не хочу использовать как ветку по умолчанию. Можно ли в новую ветку по умолчанию подтянуть имеющиеся ветки что они начинали ветвиться от неё. Пока есть только два коммита

Отслеживать
4,012 2 2 золотых знака 20 20 серебряных знаков 42 42 бронзовых знака
задан 17 сен 2022 в 8:45
495 1 1 золотой знак 4 4 серебряных знака 15 15 бронзовых знаков

Поправьте свой комментарий так, чтоб было показан вывод git log —all —10 ? Укажите какие именно комиты вы хотите перенести в другую ветку и с каким ее названием?

17 сен 2022 в 8:52
просто переименуйте ветку git branch -m желаемое_название
17 сен 2022 в 9:20

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

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

Для этого нужно выполнить интерактивный rebase , и перенести на новую начальную точку только коммиты из вашей ветки (2 штуки). Вероятнее всего rebase захочет перенести и вашу текущую ветку, и ту от которой вы ответвились. Поэтому нужен интерактивный режим.

Отслеживать
ответ дан 19 сен 2022 в 4:53
Герман Борисов Герман Борисов
10.5k 14 14 серебряных знаков 38 38 бронзовых знаков

    Важное на Мете
Похожие

Подписаться на ленту

Лента вопроса

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.1.3.2953

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Как переименовать ветку по умолчанию “default” в Git и GitLab

Git и техническое сообщество в целом недавно перешли на использование термина main для описания новой ветки по умолчанию. Другие платформы для размещения кода, такие как GitHub, внесли изменения и GitLab, как еще одна общедоступная платформа хостинга git, также внесла изменения в версии 14.0 для самостоятельных версий, выпущенных 22 июня 2021 года.

Ранее GitLab внесла изменение для пользователей GitLab.com. Переход от master к main не должен быть пугающим, на самом деле изменение имени основной ветки git-репозитория с main на master может быть довольно быстрым и простым процессом. Вам даже не нужно создавать новый репозиторий git.

Ветка по умолчанию

Если вы используете ветку main в качестве имени ветки Git по умолчанию, то, возможно, вы подумываете о переименовании своей ветки в существующих проектах, на master, как это было привычнее. Но как это сделать?

Здесь мы поговорим об использовании GitLab для переименования главной ветви в master. Репозитории Git являются одним из самых популярных инструментов отслеживания исходных текстов, используемых сегодня, и переименование «дефолтной ветки». Многие начинающие разработчики хотят следовать лучшим практикам и тенденциям и сменить свой git repo master на main или наоборот. Переименовав нашу ветвь git в новую основную ветвь, мы можем получить “main/master” в качестве нашей новой ветви. Мы также можем обновить наше соединение для отслеживания.

Переименование вашей локальной ветки

Сразу оговорюсь, что вы можете переименовать свою ветку так как вам это хочется сделать или с учетом принятых норм в вашей команде разработки. Далее мы будем рассматривать пример переименования «master» branch to «main».

Чтобы переименовать вашу локальную «главную» ветку на вашем компьютере, вам просто нужно запустить простую команду с одним вкладышем. Это обновит вашу локальную основную ветку, но не удаленную ветку. Позже нам также нужно переименовать удаленную основную ветку и изменить имя ветки по умолчанию в репозитории git.

$ git branch -m master main

Теперь мы выполним следующую команду, которая должна сообщить о результатах.

$ git status

On branch main Your branch is up to date with ‘origin/master’. nothing to commit, working tree clean

Отлично, теперь, когда мы видим, что нам удалось переименовать нашу локальную ветку, мы можем сделать то же самое и в нашем удаленном репозитории, поскольку все, что мы сделали до сих пор, не покинуло наш компьютер.

На данном этапе мы обновили текущую локальную ветку, но не обновили наш удаленный репозиторий. Наше существующее отслеживающее соединение по-прежнему указывает на master и это не привело к удалению переименованной ветки.

Переименование ветки Master

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

Пока мы находимся в нашей «дефолтной» ветке, как и раньше, мы можем отправить эту новую ветку в удаленный репозиторий.

$ git push -u origin main

На этом этапе мы должны увидеть, что теперь наш локальный репозиторий обновлен с именем удаленной ветки.

$ git status

On branch main Your branch is up to date with ‘origin/main’. nothing to commit, working tree clean

Теперь, когда у нас есть новая ветка, нам нужно убедиться, что мы меняем ветку по умолчанию в настройках проекта. Вам нужно убедиться, что у вас есть доступ как минимум на уровне Maintainer , чтобы иметь возможность делать это в GitLab.

Теперь, когда у нас есть новая ветка, нам нужно убедиться, что мы меняем ветку по умолчанию в настройках проекта. Вам нужно убедиться, что у вас есть доступ как минимум на уровне Maintainer , чтобы иметь возможность делать это в GitLab.

Это позволит нам избежать сообщения ошибке при удалении нашей старой основной ветки в нашем репозитории git. Перейдите в свой репозиторий на GitLab.com или в собственный экземпляр GitLab и перейдите в «Настройки» -> «Репозиторий». Вверху страницы настроек есть ветка Default.

После того, как мы изменили ветку и сохранили, мы можем немного прокрутить вниз и внести изменения protected статус наших веток. Новую ветку необходимо сделать защищенной (protected).

После того, как мы изменили ветку и сохранили, мы можем немного прокрутить вниз и внести изменения protected статус наших веток. Новую ветку необходимо сделать защищенной (protected).

Новую ветку нужно сделать protected, а старую ветку unprotect. Это соответсвено позволит удалить вашу старую ветку.

$ git push origin — delete master

$ git push origin — delete master

To gitlab.hatchet.com.au:

bud/seo.git — [deleted] master

1.6 Введение — Первоначальная настройка Git

Теперь, когда Git установлен в вашей системе, самое время настроить среду для работы с Git под себя. Это нужно сделать только один раз — при обновлении версии Git настройки сохранятся. Но, при необходимости, вы можете поменять их в любой момент, выполнив те же команды снова.

В состав Git входит утилита git config , которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:

  1. Файл [path]/etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр —system , то параметры будут читаться и сохраняться именно в этот файл. Так как этот файл является системным, то вам потребуются права суперпользователя для внесения изменений в него.
  2. Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра —global и применяется ко всем репозиториям, с которыми вы работаете в текущей системе.
  3. Файл config в каталоге Git (т. е. .git/config ) репозитория, который вы используете в данный момент, хранит настройки конкретного репозитория. Вы можете заставить Git читать и писать в этот файл с помощью параметра —local , но на самом деле это значение по умолчанию. Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала правильно.

Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в [path]/etc/gitconfig .

В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME ( C:\Users\$USER для большинства пользователей). Кроме того, Git ищет файл [path]/etc/gitconfig , но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git при запуске инсталлятора.

Если вы используете Git для Windows версии 2.х или новее, то так же обрабатывается файл конфигурации уровня системы, который имеет путь C:\Documents and Settings\All Users\Application Data\Git\config в Windows XP или C:\ProgramData\Git\config в Windows Vista и новее. Этот файл может быть изменён только командой git config -f , запущенной с правами администратора.

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

$ git config --list --show-origin

Имя пользователя

Первое, что вам следует сделать после установки Git — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:

$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com

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

Многие GUI-инструменты предлагают сделать это при первом запуске.

Выбор редактора

Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно проделать следующее:

$ git config --global core.editor emacs

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

В случае с Notepad++, популярным редактором, скорее всего вы захотите установить 32-битную версию, так как 64-битная версия ещё не поддерживает все плагины. Если у вас 32-битная Windows или 64-битный редактор с 64-битной системой, то выполните следующее:

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Примечание

Vim, Emacs и Notepad++ — популярные текстовые редакторы, которые часто используются разработчиками как в Unix-подобных системах, таких как Linux и Mac, так и в Windows. Если вы используете другой редактор или его 32-битную версию, то обратитесь к разделу Команды git config core.editor за дополнительными инструкциями как использовать его совместно с Git.

Предупреждение

В случае, если вы не установили свой редактор и не знакомы с Vim или Emacs, вы можете попасть в затруднительное положение, когда какой-либо из них будет запущен. Например, в Windows может произойти преждевременное прерывание команды Git при попытке вызова редактора.

Настройка ветки по умолчанию

Когда вы инициализируете репозиторий командой git init , Git создаёт ветку с именем master по умолчанию. Начиная с версии 2.28, вы можете задать другое имя для создания ветки по умолчанию.

Например, чтобы установить имя main для вашей ветки по умолчанию, выполните следующую команду:

$ git config --global init.defaultBranch main

Проверка настроек

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config —list , чтобы показать все настройки, которые Git найдёт:

$ git config --list user.name=John Doe user.email=johndoe@example.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto . 

Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из /etc/gitconfig и ~/.gitconfig ). В таком случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив git config :

$ git config user.name John Doe

Примечание

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

$ git config --show-origin rerere.autoUpdate file:/home/johndoe/.gitconfig false

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *