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

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

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

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

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

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

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

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

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

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

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

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

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

Выберите имя

В 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 , это усложнит понимание направлений.

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

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

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

Для всех существующих сборок CI обновите их, чтобы активировать их для новой ветвь по умолчанию вместо старой.
Предоставьте удостоверению сборки разрешение Участие в репозитории. Перейдите в раздел Параметры> проектаРепозитории>(ваш репозиторий)>Разрешения. Может быть до двух удостоверений: одно для службы сборки коллекции проектов, а другое — для службы сборки проектов. Убедитесь, что для разрешения Участие указано значение Разрешить.

Если новый ветвь по умолчанию имеет политики ветвей, также предоставьте удостоверению сборки политики Обхода при отправке разрешения. Это разрешение представляет угрозу безопасности, так как злоумышленник может создать конвейер, чтобы проникнуть в репозиторий в проекте. Если зеркальное отображение больше не требуется, обязательно удалите это разрешение.
Добавьте новый файл 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

Создайте новый конвейер, выбрав в мастере пункты «Azure Repos Git» и «Существующий YAML-файл Azure Pipelines». Выберите файл, mirror.yml добавленный на предыдущем шаге. Сохраните и запустите конвейер.

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

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

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

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

Установка веток по умолчанию для git push/git pull

Во время изучения git столкнулся со следующей проблемой: 1) Я могу задать ветку как ветку по умолчанию для git pull с помощью git branch —set-upstream-to remoteRep/remoteBranch находясь на этой ветке. 2) Сделать её веткой «не по умолчанию» для git pull могу с помощью git branch —unset-upstream . 3) Сделать её веткой по умолчанию для git push могу при выполнении git push -u remoteRep remoteBranch 4) А как убрать её статус tracked для git push ? Почему —unset-upstream не убирает ветку для git push ?

git init git remote add tr https://github.com/wcobalt/testrepo.git git pull tr master git remote show tr * внешний репозиторий tr URL для извлечения: https://github.com/wcobalt/testrepo.git URL для отправки: https://github.com/wcobalt/testrepo.git HEAD ветка: master Внешние ветки: b1 отслеживается master отслеживается Локальная ссылка, настроенная для «git push»: master будет отправлена в master (уже актуальна) git branch --unset-upstream fatal: Ветка «master» не имеет информации о вышестоящей ветке

Отслеживать
68k 218 218 золотых знаков 79 79 серебряных знаков 221 221 бронзовый знак
задан 21 окт 2018 в 8:39
1,182 9 9 серебряных знаков 22 22 бронзовых знака

1 ответ 1

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

команды push и pull делят между собой одну и ту же пару конфигурационных параметров: имя хранилища и имя ветки.

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

пример из конфигурационного файла хранилища:

$ grep -A 1 master .git/config [branch "master"] remote = origin merge = refs/heads/master

параметр remote («полное» имя, которое можно использовать для git config — branch.ветка.remote ) — содержит имя хранилища, а параметр merge («полное» имя — branch.ветка.merge ) — содержит имя ветки в этом хранилище.

невозможно для pull и push указать разные ветки (в удалённом хранилище) — нет двух разных параметров (типа merge-для-pull и merge-для-push ).

точно так же невозможно «привязать» ветку (сделать «tracked») по отдельности для push и pull . приведённые вами в пунктах 1 и 3 команды являются синонимами (выдержка из man git-branch ):

git branch (--set-upstream-to= | -u ) []

(технически они добавляют два параметра remote и merge в секцию [branch «ветка»] )

точно так же невозможно «отвязать» ветку (сделать «untracked») по отдельности для push и pull . приведённая вами в пункте 2 команда git branch —unset-upstream [] сделает невозможным вызов (без явного указания хранилища и ветки) как pull , так и push (технически она просто удалит оба параметра remote и merge ).

дополенение по поводу дополнения вопроса, начиная с:

Почему —unset-upstream не убирает ветку для git push ?

вы инициализировали новое хранилище, привязали к нему удалённое хранилище (под именем tr ). ни одна ветка в локальном хранилище пока не связана («tracked») ни с одной удалённой веткой. в чём можно убедиться, как заглянув в .git/conig (ни одной секции [branch «имя»] в нём нет), так и попытавшись выполнить push или pull (без явного указания параметрами имени хранилища и имени ветки).

выполнив команду git pull имя-хранилища имя-ветки , вы получили состояние указанной ветки. но всё ещё ни одна локальная ветка не стала связанной ни с одной удалённой (содержимое .git/config не изменилось).

а раз нет связанной ветки, то нечего и «отвязывать». про что вам и говорит команда branch —unset-upstream :

fatal: Ветка «master» не имеет информации о вышестоящей ветке

Как переименовать ветку по умолчанию “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.

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

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

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

$ git push origin — delete master

$ git push origin — delete master

To gitlab.hatchet.com.au:

bud/seo.git — [deleted] master

Git: установка, настройка, инициализация репозитория

Git — это распределенная система управления версиями, которая устанавливается на машину, где будет вестись работа над проектом. Грубо говоря, git — это софт, который можно скачать отсюда и установить на Linux, Windows или MacOS. В некоторых дистрибутивах Linux, git уже предустановлен, например, в Ubuntu 18/20/22. Кстати, git был разработан Линусом Торвальдсом, чтобы решить проблему командной разработки ядра Linux. Основная проблема командной разработки больших проектов в том, что со временем становится очень сложно менеджерить процессы добавления нового кода в проект, так же как и тестировать его или отлавливать баги. Git был изначально разработан с целью решить все эти проблемы. С течением времени он оброс новыми функциями, фишками и сейчас без него сложно представить разработку крупных проектов. Вот основные функции и возможности git:

Управление различными версиями проекта;
Создание и управление разными ветвями развития проекта;
Откат к предыдущим версиям проекта;
Быстрое клонирование проектов с удаленных git-серверов.

Надо сказать, что git — это не единственная система контроля версий. Есть еще Mercurial, Team Foundation Server, SVN и прочие решения, но все они сильно уступают в популярности git. В основном из-за того, что многие крупные IT-корпорации поддерживают и развивают git. Например, Microsoft, которой принадлежит gitHUB.

Если сейчас вам не совсем ясно что же такое git — не переживайте, в процессе прочтения статьи всё прояснится. Перейдем от слов к практике и пощупаем git вживую.

Работа с git: установка, настройка, создание репозитория

Как мы сказали ранее, git — это софт, который нужно установить на машину, где будет вестись разработка и настроить его. Прежде чем качать git — нужно проверить командой git —version текущую версию установленных пакетов, если ваша версия git сильно устарела, например наша версия git на Ubuntu 18 была 2.17+ (2.39 — актуальная версия), — ее следует обновить.

Установка и обновление git

Git можно установить на все популярные десктопные ОС: Windows, Linux, MacOS. В Ubuntu достаточно выполнить уже привычный многим набор команд: apt update && apt install -y git . Если git уже установлен, но версия устарела — обновить git можно так:

Скачайте репозиторий с исходниками git: git clone https://github.com/git/git;
Обновите apt-репозиторий: apt update;
Скачайте набор пакетов, необходимых для сборки GIT из исходников:
1. sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \ gettext libz-dev libssl-dev;
2. sudo apt-get install asciidoc xmlto docbook2x;
3. sudo apt-get install install-info.
1. make configure;
2. ./configure —prefix=/usr;
3. make all doc info;
4. sudo make install install-doc install-html install-info.
Ещё раз выполните команду git —version , чтобы убедиться, что git успешно обновился. Теперь можно двигаться дальше и настроить git для работы.

Настройка git

В git есть множество сущностей, одна из которых — это коммит. Коммит сохраняет разность между предыдущим сохранением и новым сохранением. При сохранении коммита записываются мета-данные — информация о том, кто сделал коммит: имя автора и электронная почта. Эти данные очень важны в командной работе, они позволяют точно идентифицировать того, кто сделал коммит.

Настройка имени и электронной почты участника команды производится локально через консоль командами:
- git config —global user.name [имя пользователя];
- git config —global user.email [электронная почта пользователя].
Если имя пользователя задается с пробелом (Имя Фамилия) — тогда его необходимо указывать в двойных кавычках, электронная почта всегда задается без кавычек. При вводе электронной почты и имени пользователя git не возвращает никакого ответа, чтобы убедиться в правильности введенных данных можно выполнить команду: git config —list .

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

Инициализация репозитория

Инициализация или создание репозитория производится командой git init в директории проекта, при этом директория как может содержать файлы проекта, так и может быть пустой. При вызове команды git init вы увидите следующее сообщение:

Тут следует обратить внимание на несколько важных вещей:
- По умолчанию git создаёт ветку master, где будут размещаться коммиты. В gitHUB же дефолтная ветка называется main — несоответствие веток может привести к проблемам в будущем, лучше сразу переименовать ветку master в main;
- Задать имя дефолтной ветки можно с помощью команды git config —global init.defaultBranch main , где main — название ветки. Эта команда работает до создания первого коммита;
- Переименовать уже существующую ветку можно командой git branch -m [название ветки] .
При инициализации репозитория в директории проекта будет создана скрытая поддиректория .git, которая содержит различные сущности git и информацию о репозитории:

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

В git есть три зоны видимости файлов:

Первая зона видимости: рабочая директория (Working directory) — это директория, содержащая файлы проекта. Просмотреть все файлы в директории можно командой ls -la .

Вторая зона видимости: индекс (Staging area) — это виртуальная зона, где фиксируются изменения внесенные в файлы проекта перед тем, как они будут сохранены (закоммичены). Посмотреть, какие изменения содержатся в индексе можно командой git status .

Третья зона видимости: репозиторий (Repository) — это сохраненные изменения, попавшие в директорию .git после коммита. В этой зоне содержатся различные git-объекты. Напрямую с ними взаимодействовать нельзя.

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

Добавление файлов в индекс

Добавить все файлы и подкаталоги проекта в индекс можно командой git add . , затем командой git status можно посмотреть, какие файлы и изменения подготовлены для коммита:

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

На этом скрине красным выделены два действия с файлами, которые пока ещё не попали в индекс: 1) Внесение изменений в файл main.py; 2) Переименование файла modules.md в python_modules.md. Отметим, что старый файл modules.md помечен теперь, как удаленный, а вот новый файл python_modules.md вообще гитом не трекается — его нужно добавить в индекс командой git add python_modules.md .

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

Кратко о GIT и его базовых настройках и командах

GIT — это система управления версиями, которая входит в многие популярные дистрибутивы Linux, например, Ubuntu 16+. Если в вашей сборке Linux нет гита из коробки, его всегда можно установить из apt (там будет не самая свежая версия) или скачать исходники с официального сайта git и скомпилировать их, как указано в нашей инструкции. Проверить версию git можно командой git —version , если git установлен корректно и версия отражается — можно переходить к созданию репозитория.

Репозиторий git — это скрытая директория .git в папке вашего проекта, где хранятся специальные git-объекты, описывающие состояние файлов и директорий вашего проекта во времени. Каждый раз, когда вы делаете коммит — вы сохраняете состояние файлов и директорий вашего проекта в git. Инициализируется или создается Git-репозиторий командой git init. После инициализации репозитория в него можно добавлять файлы для индексации.

В git есть три зоны видимости файлов:
1. Рабочая директория проекта — это видимая зона, где отражаются файлы вашего проекта в текущем коммите, если вы удалили файл и сделали коммит, то в текущем времени его больше не будет, но если откатится на предыдущий коммит, то файл там будет, так как GIT сохраняет файлы целиком;
2. Индекс или стейджинг — это невидимая зона, туда сохраняются подготовленные к коммиту изменения. Добавляются изменения в индекс командой git add . . Просмотреть изменения можно командой git status , а отправляются изменения в репозиторий командой git commit -m «комментарий» ;
3. Репозиторий — это скрытая директория .git, где в бинарном виде хранятся копии файлов и директорий. Они находятся в директории .git/objects/… Прочитать их простой командой типа cat не выйдет, для этого используется команда git cat-file -p [hash git-object] .
Краткая логическая схема работы с git-репозиторием может выглядеть так:

Коммит — это одна из базовых сущностей git. Коммиты позволяют перемещаться по разным версиям проекта. Другая организационная единица git — это ветви. Ветви позволяют логически разделять направления разработки. О коммите и ветвях мы подробно поговорим в нашей следующей статье.

Ещё одной фишкой гита является возможность быстро скачивать уже существующие репозитории с gitHUB на сервер, работать над ними и загружать обратно, часто для такой работы требуются сторонние библиотеки и модули. Для такой работы удобнее всего использовать VPS с подключением по SSH, например, от 1cloud.
Похожие публикации: