git что такое head
Ссылки в Git
Чтобы создать новую ссылку, которая поможет вам запомнить SHA-1 последнего коммита, технически, достаточно выполнить примерно следующее:
Теперь в командах Git вместо SHA-1 можно использовать только что созданную ссылку:
Тем не менее, редактировать файлы ссылок вручную не рекомендуется, вместо этого Git предоставляет более безопасную команду update-ref на случай, если вам потребуется изменить ссылку:
Вот что такое, по сути, ветка в Git — простой указатель или ссылка на последний коммит в цепочке. Для создания ветки, соответствующей предыдущему коммиту, можно выполнить следующее:
Данная ветка будет содержать лишь коммиты по указанный, но не те, что были созданы после него:
Теперь база данных Git схематично выглядит так, как показано на рисунке:
Файл HEAD — это символическая ссылка на текущую ветку. Символическая ссылка отличается от обычной тем, что она содержит не сам хеш SHA-1, а указатель на другую ссылку.
В некоторых случаях файл HEAD может содержать SHA-1 хеш какого-либо объекта. Это происходит при извлечении тега, коммита или удалённой ветки, что приводит репозиторий в состояние «detached HEAD».
Если вы заглянете внутрь HEAD, то увидите следующее:
При выполнении git commit Git создаёт коммит, указывая его родителем объект, SHA-1 которого содержится в файле, на который ссылается HEAD.
Изменить значение HEAD можно так:
Мы рассмотрели три основных типа объектов Git, но есть ещё один. Объект тега очень похож на объект коммита: он содержит имя своего автора, дату, сообщение и указатель. Разница же в том, что объект тега указывает на коммит, а не на дерево. Он похож на ветку, которая никогда не перемещается: он всегда указывает на один и тот же коммит, просто давая ему понятное имя.
Как мы знаем из главы Основы Git, теги бывают двух типов: аннотированные и легковесные. Легковесный тег можно создать следующей командой:
Что такое remotes/origin/HEAD?
Ветка develop и master понятно, что это 2 мои локальные ветки, но понятно, что такое
Я так понимаю, что это должно выглядеть так
2 ветки локальные и одна master удаленная.
Я так понял, что HEAD может указывать только на ветки удаленного репазитория. Но почему тогда после переключения на удаленную ветку дев стока HEAD все равно указывает на мастер??
Вот согласно статье на хабре
текущее состояние не изменённых файлов, находящихся под контролем версий, есть тот коммит, на который указывает HEAD
ниче не понятно, HEAD в итоге указывает на ту ветку где ты находится или на ветку в которую ты сделал последний коммит?
4 ответа 4
ветка (branch) в git — это (плавающий) указатель на commit.
удалённый репозиторий ничем не «хуже» вашего локального, и в нём тоже есть такой файл, и информация, выдаваемая командой branch :
сообщает вам о том, что этот файл в удалённом репозитории в момент клонирования содержал ссылку на ветку master (в том же, удалённом репозитории).
Я так понял, что head это та ветка в которую я делаю пуш
push вы делаете в ту ветку, которую сами и указали. либо явно, например так:
либо неявно, «привязав» вашу локальную ветку к (произвольной) ветке в удалённом репозитории, и вызывая git push без дополнительных параметров.
посмотреть «привязки» веток можно, например, командой remote show репозиторий :
по поводу дополнения к вопросу
во-первых, я уже ответил практически на тот же вопрос: Почему получаю detached head?.
во-вторых, вынесу (и дополню) сюда основное:
файл этот был создан во время клонирования и содержит информацию о том, какая именно ветка была распакована при этом в ваш рабочий каталог.
Я так понял, что HEAD может указывать только на ветки удаленного репазитория.
Но почему тогда после переключения на удаленную ветку дев стока HEAD все равно указывает на мастер?
Вот согласно статье на хабре
текущее состояние не изменённых файлов, находящихся под контролем версий, есть тот коммит, на который указывает HEAD
ниче не понятно, HEAD в итоге указывает на ту ветку где ты находится или на ветку в которую ты сделал последний коммит?
последний коммит здесь абсолютно ни при чём.
HEAD в Git это «текущая верхушка». Локальный HEAD обычно показывает место на графе коммитов, в котором сейчас находится рабочее дерево [0] (например, сделан checkout ).
На практике 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’ы и коммиты, если не выбирать другую ветку явно.» прим. пер.)
Если переместиться в ветку-отражение (посредством checkout ), Git заметит, что её нельзя [2] менять, поэтому HEAD перейдёт не в ветку, а на коммит, на котором она находится, отделившись от веток (отсюда detached HEAD ). И с этого момента надо быть осторожным.
текущее состояние не изменённых файлов, находящихся под контролем версий, есть тот коммит, на который указывает HEAD
Надеюсь, из текста выше понятно, что у вас есть HEAD (ваш) и origin/HEAD (удалённый). В статье о первом. А в списке веток есть только последний.
[0] на самом деле скорее наоборот, рабочее дерево само по себе, а HEAD нужен, чтобы вычислить и записать внесённые изменения, это «отправная точка»
[1] этот термин честно выдуман мной, употребляйте осторожно
[2] можно всё, но многие вещи ломают настолько много, что оно того не стоит
Что такое HEAD в Git?
вы видите документацию Git, говорящую такие вещи, как
ветвь должна быть полностью объединена в HEAD.
но что такое Git HEAD точно?
16 ответов
вы можете думать о голове как о «текущей ветви». При переключении ветвей с git checkout глава пересмотра изменения указывают на совет филиала.
вы можете увидеть, на что указывает голова, делая:
В моем случае, вывод такой:
HEAD может ссылаться на определенную ревизию, которая не связана с именем ветви. Эта ситуация называется отрезанная голова.
голова-это просто ссылка на объект фиксации. У каждой головы есть имя (имя ветви или имя бирки, etc). От по умолчанию, есть голова в каждом репозиторий называется master. Хранилище может содержать любое количество глав. На в любой момент времени выбирается одна голова как «нынешний руководитель».»Это голова aliased to HEAD, always in capitals».
обратите внимание на эту разницу: «голова» (нижний регистр) относится к любому один из названные головы в репозитории; » HEAD» (верхний регистр) относится исключительно к в настоящее время активный руководитель. Этот различие часто используется в Git документация.
еще один хороший источник, который быстро охватывает внутреннюю работу git (и поэтому лучшее понимание голов/головы) можно найти здесь. Ссылки (ref:) или заголовки или ветви можно рассматривать как заметки, прикрепленные к фиксациям в истории фиксации. Обычно они указывают к кончику серии коммитов, но их можно перемещать с помощью git checkout или git revert etc.
Я рекомендую это определение от разработчика GitHub Scott Chacon [прямая ссылка]:
Head-ваша текущая ветвь. Это символическая ссылка. Это ссылка на филиал. У вас всегда есть голова, но голова будет указывать на один из этих указателей, на одну из ветвей, на которых вы находитесь. Это родитель вашего следующего коммита. Это то, что должно быть тем, что было последним извлечено в ваш рабочий каталог. Это последнее известное состояние каким был ваш рабочий каталог.
все видео даст справедливое Введение во всю систему git, поэтому я также рекомендую вам посмотреть все это, если есть время.
С Pro Git книги, главы 3.1 Git ветвление-ветви в двух словах в разделе создание новой ветви:
что произойдет, если вы создадите новую ветку? Ну, это создает новый указатель для перемещения. Допустим, вы создаете новую ветвь называется тестирование. Вы делаете это с помощью команды git branch:
это создает новый указатель на ту же фиксацию, на которой вы сейчас находитесь
предполагая, что это не особый случай под названием «отделенная голова», тогда, как указано в книге О’Рейли Гита, 2-е изд., стр. 69, HEAD означает:
HEAD всегда относится к последней фиксации на текущем отделение. Когда вы меняете ветви, HEAD обновляется для ссылки на новый последнее обязательство бранча.
HEAD is «наконечник» текущей ветви.
обратите внимание, что мы можем использовать HEAD для ссылки на самую последнюю фиксацию и использования HEAD
как фиксация перед наконечником, и HEAD
2 как совершить еще раньше, и так далее.
HEAD относится к текущей фиксации, на которую указывает ваша рабочая копия, т. е. фиксации, которую вы в настоящее время проверили. От официальная документация ядра Linux по указанию ревизий Git:
HEAD имена фиксации, на которой вы основывали изменения в рабочем дереве.
вместо ввода «HEAD» вы можете сказать » @ «вместо этого, например «git log@».
HEAD-это фактически файл, содержимое которого определяет, куда относится переменная HEAD:
в этом репозитории содержимое файла HEAD ссылается на второй файл с именем refs / heads / master. Файл refs / heads / master содержит хэш последнего коммита в master-ветке.
в результате HEAD указывает на фиксацию главной ветви от .git/refs/heads / master.
Я бы хотел подробно некоторые вещи принято отвечать Грег Hewgil по. Согласно Git Карманный Гид
отрасли:
сама ветвь определяется как все точки, достижимые в фиксации график из именованной фиксации («подсказка» ветви).
руководитель: специальный тип Ref
специальная головка ref определяет, какая ветвь вы на.
Refs
Git определяет два вида ссылок или именованных указателей, которые он вызывает «refs»:
Как упоминал Грег, голова может быть в «отстраненном состоянии». Поэтому голова может быть либо a простой ref (для отдельно стоящей головы) или symref.
Если HEAD является символическим ref для существующей ветви, то вы » on» эта ветвь. Если, с другой стороны, HEAD является простым ref напрямую называя фиксацию по ее идентификатору SHA-1, Вы не находитесь » на » какой-либо ветви, но скорее в режиме «отсоединенной головы», что происходит, когда вы проверяете некоторые ранее обязались изучить.
Если вы только что клонировали и не проверили, я не знаю, на что это указывает, вероятно, какое-то недопустимое местоположение.
после прочтения всех предыдущих ответов я все еще хотел большей ясности. Этот блог на официальном сайте githttp://git-scm.com/blog дал мне то, что я искал:
голова: указатель на последний моментальный снимок фиксации, следующий родитель
голова в Git-это указатель на текущую ветку, которая в свою очередь указатель до последнего сделанного вами коммита или последнего коммита, который был зарегистрирован в вашем рабочий каталог. Это также означает, что он будет родителем следующего коммита, который вы сделаете. Обычно проще всего думать об этом, поскольку HEAD-это снимок вашего последнего коммита.
Head указывает на кончик текущей проверенной ветви.
это может быть кончик определенной ветви (например, «master») или некоторая промежуточная фиксация ветви («отдельная головка»)
эти двое могут смутить вас:
текущая ветвь, или ваше рабочее дерево обычно генерируется из дерева, на которое указывает голова. Голова должна указывать на голову, за исключением того, что вы используете отделенную голову.
рис. 3-5. Главный файл указывает на ветку, на которой вы находитесь.
как концепция, глава является последней редакцией в отрасли. Если на одну именованную ветвь приходится более одного руководителя, вероятно, вы создали ее при выполнении локальных коммитов без слияния, фактически создав безымянную ветвь.
чтобы иметь» чистый » репозиторий, вы должны иметь одну головку на именованную ветвь и всегда сливаться с именованной ветвью после локальной работы.
Git для начинающих. Часть 7. Поговорим о HEAD и tree-ish
HEAD
Во-первых, HEAD – это указатель на коммит в вашем репозитории, который станет родителем следующего коммита. Для того, чтобы лучше понять это, обратимся к репозиторию, созданному в рамках предыдущей статьи, в этом репозитории сделано шесть коммитов, посмотрим на них.
Эти коммиты создавались в порядке от самого нижнего ( a98cce4 ) к самому верхнему ( cf3d9d8 ). Каждый раз, когда мы отправляли новый коммит в репозиторий, HEAD смещался и указывал на него. Посмотрите на картинку ниже: на ней показана ситуация, когда были отправлены три первых коммита.
Текущее состояние репозитория выглядит так, как показано на рисунке ниже.
Содержимое репозитория, в данном случае, выглядит так.
Для этого передадим команде checkout идентификатор коммита.
Вернем HEAD на прежнее место.
Tree-ish
Git для начинающих. Часть 7. Поговорим о HEAD и tree-ish : 2 комментария
А можно чуть подробнее про этот момент?
“Для того, чтобы скопировать снимок репозитория относительно последнего коммита ветки master, т.е. того на который указывает HEAD, необходимо выполнить следующую команду.”
> git checkout master
Я правильно понял, что эта команда “откатывает” предыдущие изменения HEAD?
Нет, git checkout master скопирует проект из репозитория (ветка master) в рабочую директорию, при этом состояние проекта будет определяться последним коммитом, именно на него обычно указывает HEAD. Т.е. мы получаем снимок репозитория относительно последнего коммита. Надеюсь понятно объяснил))) Если что – пишите!
Машина времени в git
В последнее время мои коллеги начинают знакомство с git’ом. И один из интересующих их вопросов — как откатиться до определённой ревизии. В интернете можно найти набор команд, но хочется, чтобы было понимание каждой из них. Баловство с комадами git’а без понимания может привести к потере истории разработки.
Здесь кружочками обозначены коммиты. Чем правее коммит, тем он новее. Коммит с хэшем 6e04e..-это самый первый коммит. Одно из основных понятий, которое стоит уяснить себе новичку, — это указатели на коммиты, а точнее некоторое «прозвище» того или иного коммита. Их тьма тьмущая, например: HEAD, master, FETCH_HEAD, ORIG_HEAD и т.д. Это я перечислил крупицу стандартных прозвищ. Их можно создавать и самим, но об этом впереди.
Заострим наше внимание на двух указателях: master и HEAD. master указывает на самый старший коммит в ветке под названием master (эта ветка создаётся при инициализации репозитория). HEAD указывает на указатель master (читай, текущее состояние файлов). После появления первого коммита в репозитории, HEAD и master указывают на один и тот же коммит. И так будет продолжать до тех пор, пока не переключимся на другую ветку, не откатимся по истории, либо не совершим ряд необдуманных действий. Итак, проиллюстрируем нашу историю с указателями:
Перенос указателя HEAD ( git checkout )
Откат по истории коммитов:
Неужели мы потеряли всю историю? Как узнать самый «новый» коммит? Это не проблема — есть выход, и их несколько:
Для прояснения механизма git checkout создадим новую ветку devel:
Заметим, что указатель HEAD указывает на вершину ветки devel.
Породим в новой ветке несколько коммитов. История репозитория будет выглядеть следующим образом:
Возвращение в ветку master происходит также безболезненно:
2 :
2 :
ORIG_HEAD полезен для редактирования неверных коммитов на локальной машине (!). Предположим, что мы хотим объединить два последних коммита в единый. Для этого, сохраняя текущее состояние файлов, переводим указатель master на два коммита назад:
Посмотрим на изменения:
Ну а теперь сделаем трюк — объединяем коммиты
Вводим сообщение, сохраняемся. Теперь наша история выглядит вот так:
Важное замечание — ORIG_HEAD по-прежнему указывает на коммит d79fb… Если мы сейчас выполним команду git checkout ORIG_HEAD, то мы получим так называемое состояние detach HEAD. Оно характеризуется тем, что HEAD указывает не на вершину ветки, а просто на коммит. HEAD всегда должен указывать только на вершину какой-либо ветки!
Удачных вам путешествий по истории своего репозитория!
При подготовке материала использовались следующие источники:
Самый лучший manual — книга: ProGit
Наглядная справка по git: A Visual Git Reference (Русская версия)
UPD:
В комментариях посоветовали ещё один полезный ресурс по git`у: githowto