Git head что это

Что такое 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?.

во-вторых, вынесу (и дополню) сюда основное:

$ 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] можно всё, но многие вещи ломают настолько много, что оно того не стоит

Git: наглядная справка

Если вы не видите иллюстраций, попробуйте переключиться на версию со стандартными картинками (без SVG).

SVG изображения были отключены. (Включить SVG изображения)

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

Основные команды

Следующие четыре команды предназначены для копирования файлов между рабочей директорией, сценой, также известной как «индекс», и историей, представленной в форме коммитов.

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

Вы можете использовать git reset -p , git checkout -p , и git add -p вместо имён файлов или вместе с ними, чтобы в интерактивном режиме выбирать, какие именно изменения будут скопированы.

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

git commit -a аналогичен запуску двух команд: git add для всех файлов, которые существовали в предыдущем коммите, и git commit.
git commit файлы создаёт новый коммит, в основе которого лежат уже существующие файлы, добавляя изменения только для указанных файлов. Одновременно, указанные файлы будут скопированы на сцену.
git checkout HEAD — файлы копирует файлы из текущего коммита и на сцену, и в рабочую директорию.

Соглашения

Иллюстрации в этой справке выдержаны в единой цветовой схеме.

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

Подробно о командах

Diff

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

Commit

Когда вы делаете коммит, git создаёт новый объект коммита, используя файлы со сцены, а текущей коммит становится родителем для нового. После этого указатель текущей ветки перемещается на новый коммит. Вы это видите на картинке, где main — это текущая ветка. До совершения коммита main указывал на коммит ed489. После добавления нового коммита f0cec, родителем которого стал ed489, указатель ветки main был перемещён на новый коммит.

То же самое происходит, если одна ветка является предком другой ветки. Ниже показан пример нового коммита 1800b в ветке stable, которая является предком ветки main. После этого ветка stable уже больше не является предком ветки main. И в случае необходимости объединения работы, проделанной в этих разделённых ветках, вам следует воспользоваться командой merge (что более предпочтительно) или rebase.

Если вы сделали ошибку в последнем коммите, её легко исправить с помощью команды git commit —amend . Эта команда создаёт новый коммит, родителем которого будет родитель ошибочного коммита. Старый ошибочный коммит будет отброшен, конечно же если только на него не будет ещё каких-либо других ссылок, что маловероятно.

Четвертый случай коммита из состояния «detached HEAD» будет рассмотрен далее.

Checkout

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

Когда вы указываете имя файла (и/или ключ -p ), git копирует эти файлы из указанного коммита на сцену и в рабочую директорию. Например, git checkout HEAD~ foo.c копирует файл foo.c из коммита HEAD~ (предка текущего коммита) в рабочую директорию и на сцену. Если имя коммита не указано, то файл будет скопирован со сцены в рабочую директорию. Обратите внимание на то, что при выполнении команды checkout позиция указателя текущей ветки (HEAD) остаётся прежней, указатель никуда не перемещается.

В том случае, если мы не указываем имя файла, но указываем имя локальной ветки, то указатель HEAD будет перемещён на эту ветку, то есть мы переключимся на эту ветку. При этом сцена и рабочая директория будут приведены в соответствие с этим коммитом. Любой файл, который присутствует в новом коммите (a47c3 ниже), будет скопирован из истории; любой файл, который был в старом коммите (ed489), но отсутствует в новом, будет удалён; любой файл, который не записан ни в одном коммите, будет проигнорирован.

В том случае, если мы не указываем имя файла, и не указываем имя локальной ветки, а указываем тег, дистанционную (remote) ветку, SHA-1 хеш коммита или что-то вроде main~3, то мы получаем безымянную ветку, называемую «Detached HEAD» (оторванная голова). Это очень полезная штука, если нам надо осмотреться в истории коммитов. К примеру, вам захочется скомпилировать git версии 1.6.6.1. Вы можете набрать git checkout v1.6.6.1 (это тег, не ветка), скомпилировать, установить, а затем вернуться в другую ветку, скажем git checkout main . Тем не менее, коммиты из состояния «Detached HEAD» происходят по своим особым важным правилам, и мы рассмотрим их ниже.

Коммит из состояния «Detached HEAD»

Когда мы находимся в состоянии оторванной головы (Detached HEAD), коммит совершается по тем же правилам, что и обычно, за исключением одной маленькой особенности: ни один указатель ветки не будет изменён или добавлен к новому коммиту. Вы можете представить эту ситуацию как работу с анонимной веткой.

Если после такого коммита вы переключитесь в ветку main, то коммит 2eecb, совершённый из состояния «Detached HEAD», потеряется и попросту будет уничтожен очередной сборкой мусора только потому, что нет ни одного объекта, который бы на него ссылался: ни ветки, ни тега.

В том случае, если вы хотите сохранить этот коммит на будущее, вы можете создать на основе него новую ветку командой git checkout -b new .

Reset

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

Если коммит указан без имён файлов, указатель ветки будет перемещён на этот коммит, а затем сцена приведётся в соответствие с этим коммитом. Если мы используем ключ —soft , то сцена не будет изменена. Если мы используем ключ —hard , то будет обновлена и сцена, и рабочая директория.

Если имя коммита не будет указано, по умолчанию оно будет HEAD. В этом случае указатель ветки не будет перемещён, но сцена (а также и рабочая директория, если был использован ключ —hard ) будет приведена к состоянию последнего коммита.

Если в команде указано имя файла (и/или ключ -p ), то команда работает так же, как checkout с именем файла, за исключением того, что только сцена (но не рабочая директория) будет изменена. Если вы подставите имя коммита на место двойной черты, вы сможете получить состояние файла из этого коммита, тогда как в случае с двойной чертой вы получите состояние файла из коммита, на который указывает HEAD.

Merge

Команда merge (слияние) создает новый коммит на основе текущего коммита, применяя изменения других коммитов. Перед слиянием сцена должна быть приведена в соответствие с текущим коммитом. Самый простой случай слияния — это когда другой коммит является предком текущего коммита: в этом случае ничего не происходит. Другой простой случай слияния — когда текущий коммит является предком другого коммита: в этом случае происходит быстрая перемотка (fast-forward). Ссылка текущей ветки будет просто перемещена на новый коммит, а сцена и рабочая директория будут приведены в соответствие с новым коммитом.

Во всех других случаях выполняется «настоящее» слияние. Вы можете изменить стратегию слияния, но по умолчанию будет выполнено «рекурсивное» слияние, для которого будет взят текущий коммит (ed489 ниже на схеме), другой коммит (33104) и их общий предок (b325c); и для этих трех коммитов будет выполнено трёхстороннее слияние. Результат этого слияния будет записан в рабочую директорию и на сцену, и будет добавлен результирующий коммит со вторым родителем (33104).

Cherry Pick

Команда cherry-pick («вишенка в тортике») создаёт новый коммит на основе только одного сладкого «коммита-вишенки», применив все его изменения и сообщение.

Rebase

Перебазирование (rebase) — это альтернатива слиянию для задач объединения нескольких веток. Если слияние создаёт новый коммит с двумя родителями, оставляя нелинейную историю, то перебазирование применяет все коммиты один за одним из одной ветки в другую, оставляя за собой линейную историю коммитов. По сути это автоматическое выполнение нескольких команд cherry-pick подряд.

На схеме выше вы видите как команда берёт все коммиты, которые есть в ветке topic, но отсутствуют в ветке main (коммиты 169a6 and 2c33a), и воспроизводит их в ветке main. Затем указатель ветки перемещается на новое место. Следует заметить, что старые коммиты будут уничтожены сборщиком мусора, если на них уже ничего не будет ссылаться.

Используйте ключ —onto чтобы ограничить глубину захвата объединяемой ветки. На следующей схеме вы можете увидеть как в ветку main приходят лишь последние коммиты из текущей ветки, а именно коммиты после (но не включая) 169a6, т. е. 2c33a.

Технические заметки

Содержание файлов не хранится в индексе (.git/index) или в объектах коммитов. Правильнее было бы сказать, что каждый файл хранится в базе данных объектов (.git/objects) в двоичном представлении; найти этот файл можно по его SHA-1 хешу. В файле индекса записаны имена файлов, их хеши и дополнительная информация. В информации о коммитах вы встретите тип данных дерево, для идентификации которого также используется SHA-1 хеш. Деревья описывают директории в рабочей директории, а также содержат информацию о других деревьях и файлах, принадлежащих обозначенному дереву. Каждый коммит хранит идентификатор своего верхнего дерева, которое содержит все файлы и другие деревья, изменённые в этом коммите.

Если вы делаете коммит из состояния «оторванной головы» (detached HEAD), то на этот коммит будет ссылаться ссылка истории HEAD. Но рано или поздно время хранения этой ссылки истечёт, и этот коммит будет уничтожен сборщиком мусора точно так же, как это делается при выполнении команд git commit —amend и git rebase .

Это произведение доступно по лицензии Creative Commons Attribution-NonCommercial-ShareAlike (Атрибуция — Некоммерческое использование — С сохранением условий) 3.0 США.

Git для начинающих. Часть 7. Поговорим о HEAD и tree-ish

В этой статье мы коснемся двух понятий git , знание и понимание смысла которых позволит вам более эффективно работать с этой системой контроля версий.

HEAD

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

Во-первых, HEAD – это указатель на коммит в вашем репозитории, который станет родителем следующего коммита. Для того, чтобы лучше понять это, обратимся к репозиторию, созданному в рамках предыдущей статьи, в этом репозитории сделано шесть коммитов, посмотрим на них.

> git log --oneline cf3d9d8 [add] ignore .tmp files a7b88ee [create]: git ignore file c185b80 [create]: header for main 2b826bb [create]: main file of programm bc067c8 [add]: caption into README file a98cce4 [create repository]

Эти коммиты создавались в порядке от самого нижнего ( a98cce4 ) к самому верхнему ( cf3d9d8 ). Каждый раз, когда мы отправляли новый коммит в репозиторий, HEAD смещался и указывал на него. Посмотрите на картинку ниже: на ней показана ситуация, когда были отправлены три первых коммита.

После того как вы отправили коммит с id = 2b826bb , указатель HEAD стал показывать на него, т.е. данный коммит будет родителем для следующего, и когда мы сделаем еще один коммит, HEAD сместится.

Во-вторых, HEAD указывает на коммит, относительного которого будет создана рабочая копия во-время операции checkout . Другими словами, когда вы переключаетесь с ветки на ветку (о ветвлении в git будет рассказано в одной из ближайших статей), используя операцию checkout , то в вашем репозитории указатель HEAD будет переключаться между последними коммитами выбираемых вами ветвей.

В нашем репозитории пока только одна ветвь – master , но и этого будет достаточно, чтобы показать зависимость между положением указателя HEAD и операцией checkout .

Текущее состояние репозитория выглядит так, как показано на рисунке ниже.

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

> git checkout master Switched to branch 'master'

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

> git log --oneline cf3d9d8 [add] ignore .tmp files a7b88ee [create]: git ignore file c185b80 [create]: header for main 2b826bb [create]: main file of programm bc067c8 [add]: caption into README file a98cce4 [create repository]

Теперь передвинем указатель HEAD на коммит с id=2b826bb .

Для этого передадим команде checkout идентификатор коммита.

> git checkout 2b826bb Note: checking out '2b826bb'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 2b826bb. [create]: main file of programm

Обратите внимание на текст, который напечатал git , после того, как была выполнена эта команда. Нас интересует самая последняя строка “ HEAD is now at 2b826bb… ”, теперь HEAD указывает на коммит с id=2b826bb – именно то, что мы хотели. Посмотрим на текущий список коммитов.

> git log --oneline 2b826bb [create]: main file of programm bc067c8 [add]: caption into README file a98cce4 [create repository]

Git выводит коммиты, которые были сделаны до того коммита, на который ссылается HEAD .

Вернем HEAD на прежнее место.

> git checkout cf3d9d8 Previous HEAD position was 2b826bb. [create]: main file of programm HEAD is now at cf3d9d8. [add] ignore .tmp files > git log --oneline cf3d9d8 [add] ignore .tmp files a7b88ee [create]: git ignore file c185b80 [create]: header for main 2b826bb [create]: main file of programm bc067c8 [add]: caption into README file a98cce4 [create repository]

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

> cd .git > ls -la total 21 drwxr-xr-x 1 User 197121 0 мар 18 17:10 ./ drwxr-xr-x 1 User 197121 0 мар 18 17:10 ../ -rw-r--r-- 1 User 197121 24 мар 5 23:21 COMMIT_EDITMSG -rw-r--r-- 1 User 197121 184 мар 5 23:10 config -rw-r--r-- 1 User 197121 73 мар 5 23:10 description -rw-r--r-- 1 User 197121 41 мар 18 17:10 HEAD drwxr-xr-x 1 User 197121 0 мар 5 23:10 hooks/ -rw-r--r-- 1 User 197121 441 мар 18 17:10 index drwxr-xr-x 1 User 197121 0 мар 5 23:10 info/ drwxr-xr-x 1 User 197121 0 мар 5 23:10 logs/ drwxr-xr-x 1 User 197121 0 мар 5 23:21 objects/ drwxr-xr-x 1 User 197121 0 мар 5 23:10 refs/

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

> cat HEAD cf3d9d8f7b283267a085986e85cc8f152cca420d

HEAD указывает на коммит cf3d9d8 .

Tree-ish

Понятие tree-ish часто используется в документации по git . Tree-ish – это то, что указывает на коммит, эту сущность мы можем передавать в качестве аргумента для команд git . Вот список того, чем может являться tree-ish.

 ---------------------------------------------------------------------- | Tree-ish | Examples ---------------------------------------------------------------------- | 1. | dae86e1950b1277e545cee180551750029cfe735 | 2. | v1.7.4.2-679-g3bee7fb | 3. | master, heads/master, refs/heads/master | 4. @> | master@, HEAD@ | 5. @> | master@ | 6. @> | @ | 7. @> | @ | 8. @ | master@, @ | 9. ^ | HEAD^, v1.5.1^0 | 10. ~ | master~3 | 11. ^> | v0.99.8^ | 12. ^<> | v0.99.8^<> | 13. ^ | HEAD^ | 14. :/ | :/fix nasty bug | 15. : | HEAD:README.txt, master:sub-directory/ ---------------------------------------------------------------------- Рассмотрим работу с tree-ish на примере команды git show.

> git show cf3d9d8f -q commit cf3d9d8f7b283267a085986e85cc8f152cca420d Author: Writer writer@somecompany.com> Date: Mon Mar 5 23:21:59 2018 +0500 [add] ignore .tmp files > git show -q HEAD commit cf3d9d8f7b283267a085986e85cc8f152cca420d Author: Writer Date: Mon Mar 5 23:21:59 2018 +0500 [add] ignore .tmp files > git show -q master commit cf3d9d8f7b283267a085986e85cc8f152cca420d Author: Writer Date: Mon Mar 5 23:21:59 2018 +0500 [add] ignore .tmp files > git show -q @ commit cf3d9d8f7b283267a085986e85cc8f152cca420d Author: Writer Date: Mon Mar 5 23:21:59 2018 +0500 [add] ignore .tmp files

Во всех примерах, представленных выше, команде git show мы передаем различные tree-ish , которые на самом деле указывают на одно и тоже место – последний коммит.

Отличный курс по git делают ребята из GeekBrains , найдите в разделе “Курсы” курс “Git. Быстрый старт” , он бесплатный!

Раздел: Git Git для начинающих Метки: Git, Git для начинающих, Уроки по Git

Git для начинающих. Часть 7. Поговорим о HEAD и tree-ish : 3 комментария

Paul 12.04.2018 А можно чуть подробнее про этот момент? “Для того, чтобы скопировать снимок репозитория относительно последнего коммита ветки master, т.е. того на который указывает HEAD, необходимо выполнить следующую команду.”
> git checkout master Я правильно понял, что эта команда “откатывает” предыдущие изменения HEAD?

writer 14.04.2018 Нет, git checkout master скопирует проект из репозитория (ветка master) в рабочую директорию, при этом состояние проекта будет определяться последним коммитом, именно на него обычно указывает HEAD. Т.е. мы получаем снимок репозитория относительно последнего коммита. Надеюсь понятно объяснил))) Если что – пишите!

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