Что такое remotes/origin/HEAD?
Я так понял, что HEAD может указывать только на ветки удаленного репазитория. Но почему тогда после переключения на удаленную ветку дев стока HEAD все равно указывает на мастер??
remotes/origin/HEAD -> origin/master Вот согласно статье на хабре
текущее состояние не изменённых файлов, находящихся под контролем версий, есть тот коммит, на который указывает HEAD
ниче не понятно, HEAD в итоге указывает на ту ветку где ты находится или на ветку в которую ты сделал последний коммит?
Отслеживать
задан 10 июл 2016 в 9:05
11k 18 18 золотых знаков 64 64 серебряных знака 128 128 бронзовых знаков
head — это указатель на текущее состояние. См. habrahabr.ru/post/157175
10 июл 2016 в 10:02
зачем вы постоянно ставите метки github и gitlab?
10 июл 2016 в 10:40
@Etki ну мне так показалось как будто этот вопрос относится к ним.
10 июл 2016 в 10:41
gitlab и github — всего лишь хранилища, никак не изменяющие интерфейс гита.
10 июл 2016 в 11:19
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
ветка (branch) в git — это (плавающий) указатель на commit.
HEAD / .git/HEAD (технически) — это файл, содержащий указатель либо на текущую (для репозитория) ветку (например, файл может содержать такой текст ref: refs/heads/master ), либо на текущий commit (т.н. detached head, файл содержит строку с хэш-суммой этого commit-а).
удалённый репозиторий ничем не «хуже» вашего локального, и в нём тоже есть такой файл, и информация, выдаваемая командой branch :
remotes/origin/HEAD -> origin/master сообщает вам о том, что этот файл в удалённом репозитории в момент клонирования содержал ссылку на ветку master (в том же, удалённом репозитории).
Я так понял, что head это та ветка в которую я делаю пуш
push вы делаете в ту ветку, которую сами и указали. либо явно, например так:
$ git push репозиторий ветка либо неявно, «привязав» вашу локальную ветку к (произвольной) ветке в удалённом репозитории, и вызывая git push без дополнительных параметров.
посмотреть «привязки» веток можно, например, командой remote show репозиторий :
$ git remote show origin . Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date) по поводу дополнения к вопросу
во-первых, я уже ответил практически на тот же вопрос: Почему получаю detached head?.
во-вторых, вынесу (и дополню) сюда основное:
-
эта строка ( remotes/origin/HEAD -> origin/master ) в выдаче команды branch появляется благодаря наличию в вашем локальном хранилище файла refs/remotes/origin/HEAD , содержащего в вашем случае:
$ cat .git/refs/remotes/origin/HEAD ref: refs/remotes/origin/master Я так понял, что HEAD может указывать только на ветки удаленного репазитория.
- либо указатель на локальную ветку (т.е., содержать что-то вроде ref: refs/heads/master )
- либо хэш коммита (т.н. «состояние detached head»)
Но почему тогда после переключения на удаленную ветку дев стока HEAD все равно указывает на мастер?
remotes/origin/HEAD -> origin/master Вот согласно статье на хабре текущее состояние не изменённых файлов, находящихся под контролем версий, есть тот коммит, на который указывает HEAD
- если файл .git/HEAD содержит указатель на локальную ветку (т.е., содержит что-то вроде ref: refs/heads/master ), то, значит, у вас в рабочем каталоге распакован коммит, на который указывает локальная ветка master . хэш этого коммита хранится в файле .git/refs/heads/master
- если же файл .git/HEAD содержит хэш коммита (т.н. «состояние detached head»), то именно этот коммит сейчас и распакован в вашем рабочем каталоге.
Отслеживать
ответ дан 10 июл 2016 в 10:30
aleksandr barakin aleksandr barakin
68k 218 218 золотых знаков 79 79 серебряных знаков 221 221 бронзовый знак
Я вот такой ветки у себя ни разу не видел. Может ли вопрос автора быть связан с тем, что его удаленный репозиторий имеет рабочую копию (не является bare)?
10 июл 2016 в 10:34
Кроме того, не понятно почему HEAD удаленного репозитория вообще оказалась вытянута. Я почему-то всегда думал, что «вытягиваются» только refs/heads/* , а HEAD под этот шаблон не попадает же.
10 июл 2016 в 10:37
@PavelMayorov, Может ли вопрос автора быть связан с тем, что его удаленный репозиторий имеет рабочую копию (не является bare)? — скорее всего, так и есть. по крайней мере у меня в тестах такая строка в выдаче branch -r присутствует только в такой ситуации.
10 июл 2016 в 10:43
@PavelMayorov, «вытягиваются» только refs/heads/* — «вытягивается» то, что указано в директиве fetch в файле config. по умолчанию это +refs/heads/*:refs/remotes/origin/* . вот в refs/remotes/origin и попадает файл HEAD . и, насколько вижу, он не изменяется и остаётся таким же, каким создан при клонировании.
10 июл 2016 в 10:44
@PavelMayorov, stackoverflow.com/q/12613793/4827341
10 июл 2016 в 10:59
head это то состояния версии в которой вы в данный момент находитесь. это значит, если вы переключились на другую ветку и у вас хед позади других коммитов, значит вам нужно сделать pull , чтобы получить свежую версию этой ветки.
И для переключения между ветками лучше использовать git checkout , а для просмотра удаленных веток git remote .
Отслеживать
ответ дан 10 июл 2016 в 9:11
2,904 20 20 серебряных знаков 44 44 бронзовых знака
remotes/origin/master Это ветка, предназначенная «только для чтения». Её положение обозначает последнее известное (после последнего push / pull / fetch ) положение ветки master на сервере origin .
remotes/origin/HEAD -> origin/master HEAD в Git это «текущая верхушка». Локальный HEAD обычно показывает место на графе коммитов, в котором сейчас находится рабочее дерево [0] (например, сделан checkout ).
Но здесь другой случай. это не просто HEAD , а из origin . Как и все remote-ветки, предназначен только для чтения, но на что он указывает?
На практике origin/HEAD обычно указывает ветку по умолчанию для удалённого репозитория. Практических последствий у этого почти никаких, разве что при клонировании репозитория локальный HEAD будет там же, где на момент клонирования был HEAD на сервере. Когда вы работаете у себя на машине, origin/HEAD вам не нужен.
Ситуация становится чуть интереснее, когда к удалённому репозиторию есть интерфейс доступа. Для него HEAD может означать что-то ещё. Например, на GitHub origin/HEAD или, как у них называется, default branch можно выбрать в настройках, и прочитать пояснение о том, для чего это надо:
The default branch is considered the “base” branch in your repository, against which all pull requests and code commits are automatically made, unless you specify a different branch.
(«Ветка по умолчанию считается «основной» веткой в вашем репозитории, в которую делаются все pull-request’ы и коммиты, если не выбирать другую ветку явно.» прим. пер.)
Почему origin/* только для чтения? Эти ветки являются «отражением» [1] того, что есть на сервере origin . Поэтому эти ветки меняются только тогда, когда ваши действия меняют репозиторий в origin . Скажем, в процессе push Git передаёт серверу коммиты, дожидается его подтверждения о получении и сдвигает «отражение» на новую точку. Любые изменения в обход этого механизма рискуют сломать саму суть origin/* как отражений.
Если переместиться в ветку-отражение (посредством checkout ), Git заметит, что её нельзя [2] менять, поэтому HEAD перейдёт не в ветку, а на коммит, на котором она находится, отделившись от веток (отсюда detached HEAD ). И с этого момента надо быть осторожным.
текущее состояние не изменённых файлов, находящихся под контролем версий, есть тот коммит, на который указывает HEAD
Надеюсь, из текста выше понятно, что у вас есть HEAD (ваш) и origin/HEAD (удалённый). В статье о первом. А в списке веток есть только последний.
[0] на самом деле скорее наоборот, рабочее дерево само по себе, а HEAD нужен, чтобы вычислить и записать внесённые изменения, это «отправная точка»
[1] этот термин честно выдуман мной, употребляйте осторожно
[2] можно всё, но многие вещи ломают настолько много, что оно того не стоит
32. Что такое origin?
Мы видим, что клонированный репозиторий знает об имени по умолчанию удаленного репозитория. Давайте посмотрим, можем ли мы получить более подробную информацию об имени по умолчанию:
Выполните
git remote show origin Результат
$ git remote show origin * remote origin Fetch URL: /home/alex/githowto/repositories/work Push URL: /home/alex/githowto/repositories/work HEAD branch: main Remote branches: main tracked style tracked Local branch configured for 'git pull': main merges with remote main Local ref configured for 'git push': main pushes to main (up to date) Мы видим, что имя по умолчанию ( origin ) удаленного репозитория — изначальное work . Удаленные репозитории обычно размещаются на отдельной машине, возможно, централизованном сервере. Однако, как мы видим здесь, они могут с тем же успехом указывать на репозиторий на той же машине. Нет ничего особенного в имени origin , однако существует традиция использовать origin в качестве имени первичного централизованного репозитория (если таковой имеется).
web-steel / Шпаргалка GIT
Clone via HTTPS Clone with Git or checkout with SVN using the repository’s web address.
Learn more about clone URLs
Команды GIT
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
| HEAD — это символическое имя текущего выбранного коммита — это, по сути, тот коммит, над которым мы в данным момент работаем. |
| ^ — перемещение на один коммит назад |
| ~[num] — перемещение на [num] коммит назад |
| Комманды: |
| git —version — Узнать версию git |
| git config —global user.name «Mark Sicin» — Устанавить имя пользователя |
| git config —global user.email sicin.mark@example.com — Установить почту пользователя |
| git init — Создать пустой репозиторий |
| git init -b [branch] — Создать пустой репозиторий с начальной веткой [branch] |
| git clone https:// | git clone git:// — Клонировать существующий репозиторий |
| git add text.txt — Добавить файл в репозиторий |
| git rm text.txt — Удалить файл |
| git status — Информация о состояние файлов (изменения, неразрешенные конфликты и тд) |
| git status -s — Информация о состоянии файлов в коротком формате |
| git log —oneline — Посмотреть все коммиты в формате одной строки |
| git log —graph — Посмотеть все коммиты в формате графа |
| git commit -a -m «Commit text» — Сделать коммит с комментарием |
| git commit —amend — Изменить комментарий коммита с помощью текстового редактора. |
| git commit —amend -m «an updated commit message» — Закоммитеть новый комментарий, не открывая текстовый редактор. |
| git commit —amend —no-edit — Внести изменения в коммит без изменения комментария к нему |
| git branch [branch] — Создать новую ветку |
| git branch -f [branch] HEAD~[num] — Переместить ветку [branch] на [num] коммитов назад, относительно текущего выбранного коммита |
| git branch -f [branch] HEAD^ — Переместить ветку [branch] на один коммитов назад, относительно текущего выбранного коммита |
| git branch -f [branch] [branch1]^ — Переместить ветку [branch] на один коммитов назад, относительно ветки [branch1] |
| git branch -u [remote_branch] — Указать текущей ветке отслеживать удалённую ветку [remote_branch] |
| git checkout [branch] — Переключиться на ветку [branch] (HEAD указывает на коммит, на который указывает [branch]) |
| git checkout [commit] — Переключиться на определенный коммит (HEAD указывает на выбранный коммит) |
| git checkout -b [branch] — Создать ветку указывающую на текущем коммите и переключиться на нее |
| git checkout -b [branch1] [branch2] — Создать ветку [branch1] указывающую на ветку [branch2] и переключиться на нее |
| git checkout [branch]^ — Переключиться на один коммит назад, относительно коммита на который указывает [branch] |
| git checkout [branch]~[num] — Переключиться на [num] коммитов назад, относительно коммита на который указывает [branch] |
| git checkout HEAD^ — Переключиться на один коммит назад, относительно текущего выбраного коммита |
| git checkout HEAD~[num] — Переключиться на [num] коммитов назад, относительно текущего выбраного коммита |
| git merge [branch] — Смерждить ветку [branch] c текущей |
| git rebase [branch] — Копирует набор коммитов из текущей ветки и переносит их в [branch]. |
| git rebase [branch] [branch1] — Копирует коммиты из ветки [branch1] в ветку [branch]. |
| Отличия rebase и merge в том, что c его помощью можно делать чистые и красивые линейные последовательности коммитов. История коммитов будет чище |
| git rebase -i [branch] — Интерактивный rebase. Git откроет интерфейс просмотра того, какие коммиты готовы к копированию. Также показываются хеши коммитов и комментарии к ним, так что можно легко понять что к чему. |
| После открытия окна интерактивного rebase есть три варианта для каждого коммита: |
| — Можно сменить положение коммита по порядку, переставив строчку с ним в редакторе |
| — Можно «выкинуть» коммит из ребейза. |
| — Наконец, можно соединить коммиты. При помощи этой функции можно объединять изменения двух коммитов. |
| git cherry-pick [commit1] [commit2] [. ] — Копирование нескольких коммитов на место, где сейчас находишься (HEAD) |
| git reset HEAD^ — Отменяет изменения, перенося ссылку на один коммит назад (удаляет все ненужные коммиты) |
| git reset [branch]~[num] — Отменяет изменения, перенося ссылку на [num] коммитов назад (удаляет все ненужные коммиты) |
| git reset —soft [commit] — Отменяет изменения, оставляя все измененные файлы (удаляет все ненужные коммиты) |
| git reset —hard [commit] — Отменяет изменения, удаляя все измененные файлы (удаляет все ненужные коммиты) |
| git revert [branch] | [commit] | HEAD — Создается новый коммит. Новый коммит содержит изменения, полностью противоположные тем, что сделаны в коммите ([branch] | [commit] | HEAD). Коммит ([branch] | [commit] | HEAD), который мы хотим отменить останется в дереве коммитов для истории, но все действия, которые были в нем сделаны, будут отменены новосозданым коммитом. |
| git tag [tag] | [branch] | [commit] — Создать постоянный тег, который ссылается на конкретный коммит. Теги являются прекрасными ориентирами в истории изменений |
| git fetch — Забирает все-все данные из всех веток в ваш локальный репозиторий, но не мерджит их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент |
| git fetch origin [remote_branch] — Забирает данные из ветки [remote_branch] удаленного репозитория |
| git fetch origin [remote_branch]:[branch] — Забрать данные из ветки [remote_branch] удаленного репозитория и помещает в ветку [branch] в вашем локальном репозитории |
| git fetch origin :[branch] — Создает ветку [branch] в локальном репозитории |
| git pull — Забирает данные в ваш локальный репозиторий и мерджит с вашими наработками |
| git pull —rebase — Забирает данные в ваш локальный репозиторий и ребейзит комиты |
| git pull origin [remote_branch] — Забирает данные из ветки [remote_branch] удаленного репозитория и мерджит эти данные с текущей веткой |
| git pull origin [remote_branch]:[branch] — Забирает данные из ветки [remote_branch] удаленного репозитория, помещает данные в [branch] (если не существует git создает) локального репозитория и мерджит данные с текущей веткой |
| git push origin — Загрузка ваших изменений в указанный удалённый репозиторий |
| git push -u origin [branch] — Загрузка данных, с связыванием текущей ветки с веткой [branch] в удаленном репозитории. Если [branch] не существует, git ее создаст |
| git push origin [branch]:[remote_branch] — Запушить коммиты из ветки [branch] в ветку [remote_branch] на удаленном репохитории, если ветка [remote_branch] не существует, git ее создаст |
| git push origin :[remote_branch] — Удаляет ветку [remote_branch] из удаленного репозитория |
| git push origin +[remove_branch] — Принудительно отправить изменения в ветку [remote_branch] удаленного репозитория. Безопаснее использовать +[remote_branch], чем git push -f |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Что такое git push и как его использовать
По большому счету Git push используется для отправки локальной ветки на удаленный репозиторий. Таким образом упомянутая команда сильно облегчает процесс синхронизации в команде разработчиков, а если быть точнее, то пересылает совершенные апдейты. Если разработчик самостоятельно занимается проектом, то команда открывает возможность хранить имеющийся код в облаке, таком как github или же gitlab и прочие. Тем самым минимизируя риск потерять данные. Git pull также применяется в качестве инструмента синхронизации, который используется для получения изменений c git remote и удаленного сервера. Простыми словами разработчик может получить список удаленных подключений к репозиторию. Сейчас мы рассмотрим основные особенности запуска репозитория git. Для упрощения в статье будем использовать ”пуш”, имея в виду git push.
Отправка изменений в чистый репозиторий
Перед использованием команды git push потребуется создать связь между удаленным и локальным репозиторием. Для этого можно использовать следующую команду: git remote add
Отправка изменений
Перед пушем нужно сохранить изменения, используя git commit. После чего в терминале нужно будет прописать следующую команду: git push origin
Дополнительные опции публикации
Отправка ветки на сервер в ветку с другим именем
Git push можно назначить в другую ветку, что осуществляется с помощью готового синтаксиса. Он представляет собой имя удаленной ветки, которое указывается сразу после двоеточия: git push origin branch:server_branch В этом примере в качестве имени локальной ветки используется branch, а вот имя удаленной ветки на сервере указывается вместо server_branch.
Отправка всех веток на сервер
Просто пропишите вместо имени ветки — all: git push origin —all Затем все закомиченные апдейты во всех ветках переносятся в удаленный репозиторий.
Отправка текущей ветки
Существует очень простой и популярный метод для отправки текущей ветки с тем же именем на сервере, а именно: git push origin HEAD В данном примере на текущую ветку указывает “HEAD”. Использование такого метода убирает необходимость в запоминании имени ветки, в которой вы сейчас работаете.
Принудительная публикация (git push — force …)
При попытке отправить публикацию может возникнуть ошибка Git push rejected. Она указывает на то, что пуш отклонили. Лучше всего обратиться к подсказке к ошибке, получив и смержив изменения, а затем повторно их отправить. Данная проблема может появится в том случае, когда git проверяет, что созданный вами коммит формируется на базе предыдущих коммитов. В то время, как вы работали с частью кода, другие разработчики могли редактировать ту же часть, что и вы. Именно поэтому git не сможет провести автоматическое слияние, а ваш коммит существовал ранее и не базируется на измененных коммитах в удаленном репозитории. Для отключения проверки коммитов и при потребности в перезаписи истории используется флаг — force, или же его сокращенная версия — f: git push —force Важно! Эту команду нужно использовать с осторожностью и только иногда, так как в этом случае коммиты других разработчиков команды будут стерты.
Принудительная публикация с параметром (git push — force-with-lease …)
Более безопасный вариант принудительного пушинга изменений, но так же нежелательный. Особенность данного метода заключается в том, что он не перезаписывает изменения в удаленной ветке тогда, когда в нее были внесены коммиты от других разработчиков: git push —force-with-lease Но другие разработчики могут столкнуться с упомянутой выше ошибкой – Git push rejected
Как пушить в PhpStorm
Использовать пуш в PhpStorm достаточно просто. Изначально создайте новый проект, в правом углу среды разработки расположены распространенные команды git, среди которых команды для пушинга.
Незапушенные коммиты
Вы можете распознать коммиты, которые не запустились, следующим образом: git status В предоставленной информации будет находится название текущей ветки и то, превышает ли она версию сервера и насколько. Также можно посмотреть лог с историей коммитов с помощью команды: git log
Как пушить теги
Для создания тегов применяется git tag, а для отправки: git push origin
Удаление ветки или тега на сервере
Вы можете легко удалить ветку на удаленном репозитории с помощью команды: git push —delete origin Удалить локальную ветку можно с использованием данной команды: git branch —d Для того, чтобы удалить локальный тег: git tag —d
Продвинутые возможности
Удаление локальных данных (prune)
Удалить все имеющиеся локальные ветки, которые отсутствуют на сервере, можно с помощью следующей команды: git remote prune origin
Проверить, удастся ли пушинг (dry run option)
Данная функция фактически не произведет пушинг, однако покажет вам вывод будто он получился: git push —dry-run
Атомарный пушинг (atomic option)
Применяется, когда на сервер отправляется сразу множество веток с возможной опцией отклонения одних и успешного пушинга других. Если необходимо, чтобы отправились все ветки, либо все были отклонены используйте команду: git push —atomic origin branch1 branch2 …
Заключение
В данном обзоре мы разобрались с самыми популярными методами применения git push. Однако реальные возможности данной команды намного шире. Вы можете самостоятельно с ними ознакомится благодаря документации: git push —help