Git branch m main что это

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

Команда git branch -M main используется для переименования текущей ветки в main.

git branch -M main 

В этой команде, branch это команда Git, которая используется для работы с ветками. Опция -M означает «переименовать», и main — это новое имя для ветки.

Эта команда полезна, например, при переходе с использования термина master для главной ветки на использование термина main, что стало общепринятой практикой в сообществе разработчиков для избегания негативной коннотации слова «master».

Важно отметить, что эту команду следует выполнять, находясь в ветке, которую вы хотите переименовать.

Команда git branch используется в системе контроля версий Git для перечисления, создания или удаления ветвей.

Если вы запустите git branch без дополнительных параметров, она просто выведет список всех ветвей в вашем текущем репозитории. Текущая ветка (то есть ветка, на которой вы сейчас находитесь) будет отмечена звездочкой и выделена.

git branch 

Результат может выглядеть так:

 develop * main feature/new-feature 

В этом примере у нас есть три ветки: develop, main и feature/new-feature. Текущая ветка — main, как указано звездочкой и выделением.

Вы также можете использовать git branch с дополнительными параметрами для создания новых веток:

git branch new-branch-name 

или удаления существующих:

git branch -d branch-name-to-delete 

Copyright d00m4ace © 2024

Что делает `git branch -M main` в Git?

шел 22 год 21 века, люди впервые слышали про онлайн переводчики. Далеко не уедете без знания английского на уровне чтения документации.

19 апр 2022 в 18:02

1 ответ 1

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

-M Shortcut for --move --force. 

То есть это просто заменяет эти два параметра. Первый параметр помогает переименовать ветку, второй подавляет ряд «ошибок» — например, ветка существует.

Зачем нужна прям эта команда ? А это популярное сейчас переименование master в main, так как некоторым кажется, что master обидное. Ок, пусть будет.

Отслеживать
ответ дан 19 апр 2022 в 17:50
112k 6 6 золотых знаков 93 93 серебряных знака 159 159 бронзовых знаков

Важное на Мете

Похожие

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

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

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

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

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

Git для начинающих. Урок 7.
Работа с ветками

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Ветки — главная фишка git

Git стал стандартом в системах контроля версий благодаря простой и удобной работе с ветками.

Какие проблемы решают ветки

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

Внезапно прилетает задача — срочно поправить багу в верстке шапки. Мы не можем чинить багу прямо сейчас, в текущем состоянии проекта. У нас много изменений, но работа над большой фичей не завершена — поэтому мешать код новой фичи и код с починкой срочной баги нельзя. Как быть?

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

Когда я не пользовался git, то решал эту проблему созданием архивов проекта. Довел сайт до какого-то рабочего состояния — сделал архив. Реализовал новую фичу — сделал еще один архив. Нужно переключиться на старый код для правки баги — сохранил текущую работу в новый «временный» архив, выбрал старый «стабильный» архив, распаковал, починил там багу, вернулся обратно во «временный» архив.

Схема рабочая, но слишком много суеты и неудобств:

• нужно постоянно создавать архивы с рабочим кодом
• сложно «переключаться» между архивами
• сложно перетаскивать изменения между архивами
• легко что-то напутать или потерять — все мы люди

Все эти проблемы git решает механизмом веток.

Как работают ветки

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

Когда мы начинаем работать над новым функционалом, мы создаем новую ветку на основе master. Это называется «ответвиться от мастера». После этого мы можем работать, создавать новые файлы, вносить изменения в старые, можем хоть удалить половину проекта — главное, что это будет изолировано от основного мастера. То есть в своей ветке мы можем как угодно ломать проект, основной код при этом не пострадает.

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

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

Когда мы заканчиваем работать над новым функционалом, то нужно наши изменения перенести в мастер, чтобы залить на боевой сайт. Это называется слить ветку в мастер, или залить в мастер, или смерджить в мастер. При этом после мерджа в мастере оказываются не только наши изменения, но и те, которые были в мастере, но не были в нашей ветке (правка баги в мастере). То есть нам даже не обязательно после правки баги в мастере переносить эти изменения в свою ветку. При мердже git наш новый код «положит» поверх того, что было в мастере, не стирая старый.

Чтобы было нагляднее и понятнее, как это работает, смотрите видео. А в тексте ниже краткое описание команд для работы с ветками.

Ветка master

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

Как создать новую ветку

 $ git checkout -b news Switched to a new branch 'news' 

Так мы создали новую ветку news, имея в виду, что будем разрабатывать в ней блок новостей.

Как переключаться между ветками

Для этого используется команда checkout

 $ git checkout news 

Обратите внимание, если у вас есть незакоммиченные изменения, то переключиться на другую ветку не получится — git за этим следит

Вот что при этом вы увидите

 $ git checkout master error: Your local changes to the following files would be overwritten by checkout: index.html Please, commit your changes or stash them before you can switch branches. Aborting 

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

Как посмотреть все ветки

 $ git branch master * news 

Этой командой мы выведем список всех локальных веток. Звездочка у news означает текущую ветку, в которой мы сейчас находимся.

Коммитим в новую ветку

Коммиты в ветку добавляются точно так же, как и раньше. Делаем изменения в файлах, потом git add, потом git commit -m ‘commit message’.

Как запушить новую ветку

Вспомним, как мы пушили раньше

 $ git push origin master 

Точно так же мы пушим и новую ветку, только вместо master указываем свое название

 $ git push origin news 

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

Как переименовать ветку

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

 $ git branch -m block-news 

Это переименует текущую ветку news в block-news. Чтобы убедиться, посмотрим список веток

 $ git branch * block-news master 

Обратите внимание, если мы запушим новую ветку, то на сервере, в github, появится еще одна ветка block-news, и при этом останется старая news. Чтобы не засорять проект, старую ветку нужно удалить как локальную у себя, так и удаленную на сервере.

Как удалить ветку

Удаляется ветка командой git branch -d branch_name. Но здесь могут быть варианты. Рассмотрим, что может пойти не так

 $ git branch -d block-news error: Cannot delete the branch 'block-news' which you are currently on. 

Здесь просто — мы не можем удалить ветку, потому что в ней находимся. Сначала нужно перелючиться в мастер

 $ git checkout master $ git branch -d block-news error: The branch 'block-news' is not fully merged. If you are sure you want to delete it, run 'git branch -D block-news'. 

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

 $ git branch -D block-news Deleted branch block-news (was cb38a55). 

Теперь удалено без вопросов.

Как работать с ветками в PhpStorm

В правом нижнем углу есть пункт «Git:master». Там пишется название текущей ветки. Чтобы создать новую, нужно кликнуть на этот пункт и выбрать New Branch. Чтобы переключиться, выбрать в списке Local Branches нужную ветку и Checkout. Чтобы удалить или переименовать соотвественно Delete или Rename.

Наглядно это показывается в видеоуроке

Раздел Remote Branches мы рассмотрим в следующем уроке

Что могу посоветовать

• научитесь легко оперировать ветками
• создавайте больше веток
• называйте ветки по общим правилам
• пушьте ветки почаще, их легко потом удалить

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

И напоследок Киану. Просветление. Назад возврата нет

В следующем уроке мы узнаем, как работать с ветками на сервере

Спасибо за внимание и до встречи!

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
• 16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
• 24. Мердж-реквесты
• * 25. Форки

3.1 Ветвление в Git — О ветвлении в двух словах

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

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

О ветвлении в двух словах

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

Как вы можете помнить из Что такое Git?, Git не хранит данные в виде последовательности изменений, он использует набор снимков (snapshot).

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

Предположим, у вас есть каталог с тремя файлами и вы добавляете их все в индекс и создаёте коммит. Во время индексации вычисляется контрольная сумма каждого файла (SHA-1 как мы узнали из Что такое Git?), затем каждый файл сохраняется в репозиторий (Git называет такой файл блоб — большой бинарный объект), а контрольная сумма попадёт в индекс:

$ git add README test.rb LICENSE $ git commit -m 'Initial commit'

Когда вы создаёте коммит командой git commit , Git вычисляет контрольные суммы каждого подкаталога (в нашем случае, только основной каталог проекта) и сохраняет его в репозитории как объект дерева каталогов. Затем Git создаёт объект коммита с метаданными и указателем на основное дерево проекта для возможности воссоздать этот снимок в случае необходимости.

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

Рисунок 9. Коммит и его дерево

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

Рисунок 10. Коммит и его родители

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

Примечание

Ветка «master» в Git — это не какая-то особенная ветка. Она точно такая же, как и все остальные ветки. Она существует почти во всех репозиториях только лишь потому, что её создаёт команда git init , а большинство людей не меняют её название.

Рисунок 11. Ветка и история коммитов

Создание новой ветки

Что же на самом деле происходит при создании ветки? Всего лишь создаётся новый указатель для дальнейшего перемещения. Допустим вы хотите создать новую ветку с именем testing . Вы можете это сделать командой git branch :

$ git branch testing

В результате создаётся новый указатель на текущий коммит.

Рисунок 12. Две ветки указывают на одну и ту же последовательность коммитов

Как Git определяет, в какой ветке вы находитесь? Он хранит специальный указатель HEAD . Имейте ввиду, что в Git концепция HEAD значительно отличается от других систем контроля версий, которые вы могли использовать раньше (Subversion или CVS). В Git — это указатель на текущую локальную ветку. В нашем случае мы всё ещё находимся в ветке master . Команда git branch только создаёт новую ветку, но не переключает на неё.

Рисунок 13. HEAD указывает на ветку

Вы можете легко это увидеть при помощи простой команды git log , которая покажет вам куда указывают указатели веток. Эта опция называется —decorate .

$ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9 Initial commit

Здесь можно увидеть указывающие на коммит f30ab ветки: master и testing .

Переключение веток

Для переключения на существующую ветку выполните команду git checkout . Давайте переключимся на ветку testing :

$ git checkout testing

В результате указатель HEAD переместится на ветку testing .

Рисунок 14. HEAD указывает на текущую ветку

Какой в этом смысл? Давайте сделаем ещё один коммит:

$ vim test.rb $ git commit -a -m 'made a change'

Рисунок 15. Указатель на ветку HEAD переместился вперёд после коммита

Интересная ситуация: указатель на ветку testing переместился вперёд, а master указывает на тот же коммит, где вы были до переключения веток командой git checkout . Давайте переключимся назад на ветку master :

$ git checkout master

Примечание
git log не показывает все ветки по умолчанию

Если выполнить команду git log прямо сейчас, то в её выводе только что созданная ветка «testing» фигурировать не будет.

Ветка никуда не исчезла; просто Git не знает, что именно она вас интересует, и выводит наиболее полезную по его мнению информацию. Другими словами, по умолчанию git log отобразит историю коммитов только для текущей ветки.

Для просмотра истории коммитов другой ветки необходимо явно указать её имя: git log testing Чтобы посмотреть историю по всем веткам — выполните команду с дополнительным флагом: git log —all .

Рисунок 16. HEAD перемещается когда вы делаете checkout

Эта команда сделала две вещи: переместила указатель HEAD назад на ветку master и вернула файлы в рабочем каталоге в то состояние, на снимок которого указывает master . Это также означает, что все вносимые с этого момента изменения будут относиться к старой версии проекта. Другими словами, вы откатили все изменения ветки testing и можете продолжать в другом направлении.

Примечание
Переключение веток меняет файлы в рабочем каталоге

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

Давайте сделаем ещё несколько изменений и создадим очередной коммит:

$ vim test.rb $ git commit -a -m 'made other changes'

Теперь история вашего проекта разошлась (см Разветвлённая история). Вы создали ветку и переключились на неё, поработали, а затем вернулись в основную ветку и поработали в ней. Эти изменения изолированы друг от друга: вы можете свободно переключаться туда и обратно, а когда понадобится — объединить их. И всё это делается простыми командами: branch , checkout и commit .

Рисунок 17. Разветвлённая история

Все описанные действия можно визуализировать с помощью команды git log . Для отображения истории коммитов, текущего положения указателей веток и истории ветвления выполните команду git log —oneline —decorate —graph —all .

$ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Made other changes | * 87ab2 (testing) Made a change |/ * f30ab Add feature #32 - ability to add new formats to the central interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9 initial commit of my project

Ветка в Git — это простой файл, содержащий 40 символов контрольной суммы SHA-1 коммита, на который она указывает; поэтому операции с ветками являются дешёвыми с точки зрения потребления ресурсов или времени. Создание новой ветки в Git происходит так же быстро и просто как запись 41 байта в файл (40 знаков и перевод строки).

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

Давайте посмотрим, почему и вам имеет смысл делать так же.

Примечание
Одновременное создание новой ветки и переключение на неё

Как правило, при создании новой ветки вы хотите сразу на неё переключиться — это можно сделать используя команду git checkout -b .

Примечание

Начиная с Git версии 2.23, вы можете использовать git switch вместо git checkout , чтобы:

• Переключиться на существующую ветку: git switch testing-branch .
• Создать новую ветку и переключиться на неё: git switch -c new-branch . Флаг -c означает создание, но также можно использовать полный формат:` —create`.
• Вернуться к предыдущей извлечённой ветке: git switch — .