Git checkout что делает

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 .

Copyright © 2010, Mark Lodato. Russian translation © 2012, Alex Sychev.

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

A3.4 Приложение C: Команды Git — Ветвление и слияния

За создание новых веток и слияние их воедино отвечает несколько Git команд.

git branch

Команда git branch — это своего рода «менеджер веток». Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.

Большая часть главы Ветвление в Git посвящена этой команде, она используется повсеместно в этой главе. Впервые команда branch была представлена в разделе Создание новой ветки главы 3, а большинство таких её возможностей как перечисление и удаление веток были разобраны в разделе Управление ветками главы 3.

В разделе Отслеживание веток главы 3 мы показали как использовать сочетание git branch -u для отслеживания веток.

Наконец, мы разобрались что происходит за кулисами этой команды в разделе Ссылки в Git главы 10.

git checkout

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

Мы познакомились с этой командой в разделе Переключение веток главы 3 вместе с git branch .

В разделе Отслеживание веток главы 3 мы узнали как использовать флаг —track для отслеживания веток.

В разделе Использование команды checkout в конфликтах главы 7 мы использовали эту команду с опцией —conflict=diff3 для разрешения конфликтов заново, в случае если предыдущее решение не подходило по некоторым причинам.

Мы рассмотрели детали взаимосвязи этой команды и git reset в разделе Раскрытие тайн reset главы 7.

Мы исследовали внутренние механизмы этой команды в разделе HEAD главы 10.

git merge

Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.

Мы познакомили вас с этой командой в разделе Основы ветвления главы 3. И хотя git merge встречается в этой книге повсеместно, практически все использования имеют вид git merge с указанием единственной ветки для слияния.

Мы узнали как делать «сплющенные» слияния (когда Git делает слияние в виде нового коммита, без сохранения всей истории работы) в конце раздела Форк публичного проекта.

В разделе Продвинутое слияние главы 7 мы глубже разобрались с процессом слияния и этой командой, включая флаги -Xignore-all-whitespace и —abort , используемый для отмены слияния в случае возникновения проблем.

Мы научились проверять криптографические подписи перед слияниями если ваш проект использует GPG в разделе Подпись коммитов главы 7.

Ну и наконец в разделе Слияние поддеревьев главы 7 мы познакомились со слиянием поддеревьев.

git mergetool

Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.

Мы вкратце упомянули о ней в разделе Основные конфликты слияния главы 3 и рассказали как настроить свою программу слияния в разделе Внешние программы слияния и сравнения главы 8.

git log

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

Практически во всех главах книги эта команда используется для демонстрации истории проекта.

Мы познакомились c git log и некоторыми её деталями в разделе Просмотр истории коммитов главы 2. Там мы видели использование опций -p и —stat для получения представления об изменениях в каждом коммите, а также —pretty and —oneline для настройки формата вывода этой команды — более полным и подробным или кратким.

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

В разделах Небольшая команда главы 5 и Диапазоны коммитов главы 7 мы познакомили вас с синтаксисом branchA..branchB , позволяющем команде git log показывать только коммиты, присутствующие в одной ветке, но отсутствующие в другой. Мы довольно подробно рассматриваем этот вопрос в разделе Диапазоны коммитов.

В разделах История при слиянии и Три точки главы 7 мы рассмотрели синтаксис branchA…​branchB и опцию —left-right позволяющие увидеть, что находится в одной или в другой ветке, но не в них обеих сразу. Также в разделе История при слиянии мы рассмотрели опцию —merge , которая может быть полезной при разрешении конфликтов, а также —cc для просмотра конфликтов слияния в истории проекта.

В разделе RefLog-сокращения главы 7 мы использовали опцию -g для вывода git reflog , используя git log .

В разделе Поиск главы 7 мы рассмотрели использование опций -S и -L для поиска событий в истории проекта, например, истории развития какой-либо фичи.

В разделе Подпись коммитов главы 7 мы показали, как использовать опцию —show-signature для отображения строки валидации подписи для каждого коммита в git log .

git stash

Команда git stash используется для временного сохранения всех незафиксированных изменений с целью очистки рабочего каталога без необходимости фиксировать незавершённую работу в текущей ветке.

Эта команда практически целиком раскрыта в разделе Припрятывание и очистка главы 7.

git tag

Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.

Мы познакомились и разобрались с ней в разделе Работа с тегами главы 2 и использовали на практике в разделе Помечайте свои релизы главы 5.

Мы научились создавать подписанные с помощью GPG метки, используя флаг -s , и проверять их, используя флаг -v , в разделе Подпись главы 7.

Git checkout что делает

Полезные команды Git для веб-разработчиков

Git — это незаменимый инструмент в ежедневной работе каждого разработчика. Знание команд, о которых мы подробно расскажем в этой статье, повысят вашу производительность вдвое!

Веб-разработка
13 авг. 2021

git checkout —

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

git checkout -

С помощью команды git checkout вы также сможете отменить изменения файла и возвратить его в первичное состояние. Чтобы сделать отмену изменения файла, необходимо прописать git checkout .

git add -p git add.

git bisect start git bisect good git bisect bad

git commit –amend

git rebase -i HEAD ~ n

git grep "www.hostinger.ru"