как узнать в какой ветке находишься git

Управление ветками

Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.

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

Вы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.

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

Не переименовывайте ветки, которые всё ещё используются другими участниками. Не переименовывайте ветку в master/main/mainline, не прочитав раздел «Изменение имени главной ветки».

Теперь проверим, где мы сейчас находимся:

Теперь старое имя ветки полностью заменено исправленным.

Изменение имени главной ветки

Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. Прежде чем сделать это, обязательно проконсультируйтесь с коллегами. Также убедитесь, что вы выполнили тщательный поиск в своём репозитории и обновили все ссылки на старое имя ветки в вашем коде или скриптах.

Переименуйте локальную ветку master в main с помощью следующей команды:

В итоге, состояние репозитория становится следующим:

Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:

Все проекты, которые зависят от текущего, должны будут обновить свой код и/или конфигурацию.

Обновите конфигурацию всех запускаемых тестов.

Исправьте скрипты сборки и публикации артефактов.

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

Обновите документацию, исправив ссылки, указывающие на старую ветку.

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

Источник

Как узнать в какой ветке находишься git

Создание репозиториев

git init [project-name] — создать новый локальный репозиторий с заданным именем.

git clone [url] — загрузить проект и его полную историю изменений.

Работа с изменениями

git status — полный список изменений файлов, ожидающих коммита.

git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).

git add [file] — сделать указанный файл готовым для коммита.

git add ‘*.txt’ — добавить только файлы, соответствующие указанному выражению.

git diff HEAD — показать что изменилось с последнего коммита.

git diff HEAD^ — показать что изменилось с предпоследнего коммита.

git diff [branch] — сравнить текущую ветку с заданной.

git reset [file] — убрать файлы из индекса коммита (изменения не теряются).

git commit — записать изменения в репозиторий. для написания сообщения откроется назначенный редактор.

Работа с ветками

git branch — список всех локальных веток в текущей директории.

git branch [branch-name] — создать новую ветку.

git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.

git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.

git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.

Работа с файлами

git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.

git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.

Отслеживание файлов

.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:

Сохранение фрагментов

git stash — положить во временное хранилище все отслеживаемые файлы.

git stash pop — восстановить последние файлы, положенные во временное хранилище.

git stash list — список всех сохраненных изменений во временном хранилище.

git stash drop — удалить последние файлы, положенные во временное хранилище.

Просмотр истории

git log — список изменения текущей ветки.

git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.

git show [commit] — показать метадату и изменения в заданном коммите.

git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.

Отмена коммитов

git reset — убрать изменения из индекса коммита, сами изменения останутся.

git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.

Синхронизация изменений

git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.

git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.

git push — запушить текущую ветку в удаленную ветку.

git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.

git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.

git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.

git pull [remote][branch] — указать конкретную удаленную ветку для слияния.

git remote — посмотреть список доступных удаленных репозиториев.

git remote add [remote][url] — добавить новый удаленный репозиторий.

Источник

git узнать текущую ветку

Список локальных веток

Чтобы вывести список локальных веток используется команда:

Список удаленных веток

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

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

Список всех веток

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

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

Однако проблема заключается в том, что команда выводит список всех веток, помечая рабочую ветку звездочкой (*):

Из всего этого списка нам нужно вычленить название dev, да еще и без звездочки.

Есть сервер git, туда я поставил web-интерфейс, и надо прикрутить ctags на файлы, для этого надо обработать каждый push в hook’ах, решил я сделать две ветки на репозитории origin:

Надо теперь как то узнавать элейес репозитория (origin или др.), и ветку, по http такая информация не передается.

проделал я в локальном репе:

после этого я посмотрел файл head:

в .git/HEAD на клиенте: ref: refs/heads/dev
на сервере ref: refs/heads/master

dev была создана после master

но HEAD по сути должен же указывать на последний коммит в дереве изменений? Почему на сервере master?

вот еще выполнил на сервере:

1 ответ 1

предварительное напоминание

в git-е веткой (branch) называется «скользящий» указатель на commit, а не набор commit-ов, как принято в некоторых других системах управления контролем версий.

но HEAD по сути должен же указывать на последний коммит в дереве изменений? Почему на сервере master?

в bare-репозитории файл HEAD ссылается на «ветку по умолчанию», что в первую очередь влияет на результаты клонирования этого репозитория: если при клонировании не указано, на какую ветку следует переключить рабочий каталог (working directory) по окончании клонирования, именно на эту ветку и произойдёт переключение.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Работа с ветками в GIT

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

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

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

На момент выполнения команды вы находились в какой-то ветке, допустим в master. Состояние этой ветки будет скопировано в ветку testing, и в testing можно будет редактировать файлы и делать снимки, не трогая пока основную ветку master.

Переключение на ветку

Предыдущая команда создаст ветку, но не переключит нас на нее, мы все еще останемся работать в старой ветке. Чтобы перейти на ветку testing и начать работать в ней, выполним команду:

Имейте в виду, что GIT не позволит перейти на другую ветку, если в текущей ветке — в которой мы находимся — есть изменения, которые не зафиксированы (commit) либо не спрятаны (stash). Это нормально, ведь при смене ветке в текущем каталоге сменятся файлы, и git-у надо знать, как быть с текущими изменениями.

Создание и переключение единой командой

Чтобы не выполнять предыдущие команды по очереди, можно написать их одной строкой:

Эта команда создаст ветку testing и сразу переключит нас на нее. Обычно именно это и требуется сделать.

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

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

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

Теперь можно посмотреть, какие ветки есть в удаленном репозитории:

Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:

Вообще-то можно было написать проще:

Как создать подветку ветки

Обычно мы ответвляемся от основной ветки master, но не всегда. Иногда требуется сделать ответвление от созданной ветки — так сказать, ответвление второго порядка.

Предыдущая команда, с помощью которой мы создавали ветку:

создает ответвление от основной ветки master.

Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:

Первая команда переключит нас на ветку testing.
Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
Как понятно из имени, subbranch_of_testing – это подветка ветки testing.

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

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

Появится список веток. Текущая ветка будет выделена звездочкой.

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

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

Локальную

Если еще не выполнена команда push, то достаточно переименовать локальную ветку.

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

Например, переименуем ветку testing в ветку test:

Чтобы переименовать текущую ветку, выполним команду:

Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:

Удаленную

Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:

здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),
old-name — имя ветки локальной ветки,
new-name — новое имя ветки в удаленном репозитории.

Например, надо переименовать ветку testing в test:

Удаление локальной ветки

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

Флаги:
-D сокращение для —delete –force удаляет ветку независимо от того, слиты ли ее изменения
-d сокращение для —delete
Например, удалим локальную ветку test:

Вообще-то локальную ветку обычно удаляют после того, как слили ее (выполнили merge) в ветку master, смотрите последний раздел в статье о слиянии веток.

Удаление ветки из удаленного репозитория

Чтобы удалить удаленную ветку, можно использовать две записи.
Либо через двоеточие, как мы уже делали при переименовании ветки:

Например, удалим ветку test из удаленного репозитория origin:

Либо с флагом —delete, так понятнее:

здесь origin — имя удаленного репозитория

Как слить ветки

Обычно сливают некоторую ветку (например, ветку-багфикс) в ветку master. Для этого сначала перейдем в ветку master (в ту ветку, в которую вливаем изменения):

А затем выполним слияние. Допустим, в ветку master надо слить ветку test :

Слияние веток не всегда происходит гладко, иногда требуется разрешить конфликты вручную. Для этого надо отредактировать конфликтые файлы, выполнить их commit.

В этой статье мы рассмотрели работу с ветками GIT и составили небольшую шпаргалку по использованию веток.

Источник