Как сделать коммит в git через консоль

A3.3 Приложение C: Команды Git — Основные команды

Всего несколько команд нужно для базового варианта использования Git для ведения истории изменений.

git add

Команда git add добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.

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

Знакомство с этой командой происходит в разделе Отслеживание новых файлов главы 2.

О том как использовать git add для разрешения конфликтов слияния написано в разделе Основные конфликты слияния главы 3.

В разделе Интерактивное индексирование главы 7 показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.

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

git status

Команда git status показывает состояния файлов в рабочем каталоге и индексе: какие файлы изменены, но не добавлены в индекс; какие ожидают коммита в индексе. Вдобавок к этому выводятся подсказки о том, как изменить состояние файлов.

Мы познакомили вас с этой командой в разделе Определение состояния файлов главы 2, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.

git diff

Команда git diff используется для вычисления разницы между любыми двумя Git деревьями. Это может быть разница между вашей рабочей копией и индексом (собственно git diff ), разница между индексом и последним коммитом ( git diff —staged ), или между любыми двумя коммитами ( git diff master branchB ).

Мы познакомили вас с основами этой команды в разделе Просмотр индексированных и неиндексированных изменений главы 2, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.

О том как использовать эту команду для проверки на проблемы с пробелами с помощью аргумента —check можно почитать в разделе Правила создания коммитов главы 5.

Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…​B в разделе Определение применяемых изменений главы 5.

В разделе Продвинутое слияние главы 7 показано использование опции -w для скрытия различий в пробельных символах, а также рассказано как сравнивать конфликтующие изменения с опциями —theirs , —ours и —base .

Использование этой команды с опцией —submodule для сравнения изменений в подмодулях показано в разделе Начало работы с подмодулями главы 7.

git difftool

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

Мы лишь вкратце упомянули о ней в разделе Просмотр индексированных и неиндексированных изменений главы 2.

git commit

Команда git commit берёт все данные, добавленные в индекс с помощью git add , и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.

Вы познакомились с основами модели коммитов в разделе Коммит изменений главы 2. Там же мы продемонстрировали использование опций -a для добавления всех изменений в индекс без использования git add , что может быть удобным в повседневном использовании, и -m для передачи сообщения коммита без запуска полноценного редактора.

В разделе Операции отмены главы 2 мы рассказали об опции —amend , используемой для изменения последнего совершённого коммита.

В разделе О ветвлении в двух словах главы 3 мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.

Мы показали вам как подписывать ваши коммиты, используя опцию -S в разделе Подпись коммитов главы 7.

И наконец мы заглянули внутрь команды git commit в разделе Объекты коммитов главы 10 и узнали что она делает за кулисами.

git reset

Команда git reset , как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель HEAD и, опционально, состояние индекса. Также эта команда может изменить файлы в рабочем каталоге при использовании параметра —hard , что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.

Мы рассказали об основах использования git reset в разделе Отмена индексации файла главы 2, где эта команда использовалась для удаления файла из индекса, добавленного туда с помощью git add .

В разделе Раскрытие тайн reset, полностью посвящённой этой команде, мы разобрались в деталях её использования.

Мы использовали git reset —hard чтобы отменить слияние в разделе Прерывание слияния главы 7, там же было продемонстрировано использование команды git merge —abort для этих целей, которая работает как обёртка над git reset .

git rm

Команда git rm используется в Git для удаления файлов из индекса и рабочей копии. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.

Мы немного разобрались с этой командой в разделе Удаление файлов главы 2, показали как удалять файлы из рабочего каталога и индекса и только из индекса, используя флаг —cached .

Ещё один вариант использования git rm приведён в разделе Удаление объектов главы 10, где мы вкратце объяснили как использовать опцию —ignore-unmatch при выполнении git filter-branch , которая подавляет ошибки удаления несуществующих файлов. Это может быть полезно для автоматически выполняемых скриптов.

git mv

Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.

Мы лишь вкратце упомянули эту команду в разделе Перемещение файлов главы 2.

git clean

Команда git clean используется для удаления мусора из рабочего каталога. Это могут быть результаты сборки проекта или файлы конфликтов слияний.

Мы рассмотрели множество опций и сценариев использования этой команды в разделе Очистка рабочего каталога главы 7.

1.4 Введение — Командная строка

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

Поэтому мы предполагаем, что вы знаете, как открыть терминал в Mac или командную строку, или PowerShell в Windows. Если вам не понятно, о чем мы здесь говорим, то вам, возможно, придётся ненадолго прерваться и изучить эти вопросы, чтобы вы могли понимать примеры и пояснения из этой книги.

About this site
Patches, suggestions, and comments are welcome.

Git is a member of Software Freedom Conservancy

Работа с системой контроля версий git из консоли

Git – это распределённая система контроля версий, которую создал Линус Торвальдс в процессе разработки ядра Linux.

Ключевой особенностью системы является её децентрализованность. Благодаря git вы можете вносить изменения в ветку (branch), которая хранится в репозитории (хранилище) на удалённом сервере и видна другим разработчикам. С другой стороны, вы можете создать свою локальную ветку, которая будет видна только на вашей рабочей станции. Однако в любой момент вы можете сделать её общедоступной, разместив в репозитории на удалённом сервере. А можете произвести слияние (merge) вашей локальной ветки с репозиторием так, что на сервере она будет выглядеть частью «ствола» дерева изменений.

В настоящий момент git как система контроля версий является стандартом среди разработчиков, поэтому давайте рассмотрим эту систему более подробно. Начнём с установки и настройки.

Установка

Установка под Ubuntu выполняется одной командой:

sudo apt install git

Настройка

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

git config —global user.name «Ivan Petrov»
git config —global user.email «ivan.petroff@test.com»

Все эти глобальные параметры вы также можете посмотреть и отредактировать в файле .gitconfig в вашей домашней директории. Под Ubuntu это /home/имя_пользователя/.gitconfig.

Глобальные параметры можно переопределить на уровне отдельного проекта. Для этого находясь в папке проекта, выполните указанные выше команды, убрав флаг —global.

Создание локального хранилища

В самом простом случае при помощи git можно организовать локальный репозиторий, в котором вы можете фиксировать изменения «для себя». Перейдём в любую директорию и создадим там пустой репозиторий:

Клонирование репозитория

Если вы хотите скопировать уже существующий репозиторий, который размещён в централизованном хранилище (например, github), то вместо инициализации локального репозитория вам нужно его склонировать, используя url репозитория.

Этот url вы можете найти на главной странице репозитория в github, как показано на картинке выше.

git clone git@github.com:devmarkru/spring-jpa-rest-kotlin.git

После выполнения этой команды в текущей папке у вас появится папка проекта spring-jpa-rest-kotlin.

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

Состояние хранилища

Теперь давайте создадим в папке нашего проекта какой-нибудь текстовый файл, например, test.txt. В нём сохраним произвольный текст. А затем посмотрим в консоли текущее состояние хранилища:

# выводим строку текста и сразу сохраняем её в файл
echo «Some text string» > test.txt
# смотрим статус репозитория
git status

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

Добавление файла к git

В данном случае статус нам покажет, что появился «untracked» файл, который ещё не добавлен в систему контроля версий. Давайте добавим его, чтобы для него учитывалась история изменений.

git add test.txt

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

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

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

Фиксация изменений (commit)

Зафиксируем изменение файла test.txt в репозитории. Обязательно используйте опцию -m для указания пояснительного текста к изменению

# создание коммита
git commit -m «file test.txt added»

Если же вы хотите добавить многострочный комментарий при помощи текстового редактора, то можете выполнить просто git commit без параметров. В этом случае откроется текстовый редактор (например, nano или vim) и вы сможете ввести многострочный комментарий. После этого сохраните получившийся файл.

Просмотр истории изменений

Теперь это сообщение можно увидеть в истории изменений нашего проекта:

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

Изменим содержимое нашего файла test.txt. Его статус изменится на modified. Выполним второй коммит, чтобы зафиксировать это изменение. Обратите внимание, что второй раз команду git add выполнять не нужно.

echo «Some other text» > test.txt
git add .
git commit -m «second commit»

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

Удаление файла из git

Теперь удалим наш файл test.txt и сделаем третий коммит.

git rm test.txt
git commit -m «file removed»

Обратите внимание, что, если файл уже был добавлен к git, его нельзя удалять стандартной командой rm, а надо делать это средствами git.

Постраничный просмотр истории изменений

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

Также можно использовать более компактный вариант лога:

git log —pretty=oneline

В общем-то, этих операций достаточно, чтобы обеспечить базовое версионирование на отдельно взятой рабочей станции.

Работа с ветками (branches)

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

git branch -a # все ветки
git branch -r # только remote-ветки
git branch -l # только локальные ветки

Активная ветка, т.е. та, в которой вы находитесь сейчас, будет отмечена звёздочкой.

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

git checkout имя_ветки

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

Создать новую ветку и сразу перейти в неё:

git checkout -b имя_новой_ветки

Имя локальной ветки бывает удобно указывать по номеру задачи в вашей системе управления задач (например, Jira).

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

git checkout -b локальное_имя_ветки origin/имя_ветки_на_сервере

Работа с удалённым репозиторием

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

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

Общий вид команды для получения изменений с сервера:

git pull origin имя_локальной_ветки:имя_ветки_на_сервере

Можно также использовать сокращённый вариант:

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

Общий вид команды для отправки изменений на сервер:

git push origin имя_локальной_ветки:имя_ветки_на_сервере

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

Можно также использовать сокращённый вариант:

git push HEAD :имя_ветки_на_сервере

HEAD – это алиас, который всегда указывает на вашу текущую ветку.

Итоги

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

Гайд по Git : Часть 1 : Как сделать коммит в Git

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

29 мая 2021 · 10 минуты на чтение

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

Я пользовался git еще в универе, было удобно писать диплом и не плодить 100 копий файлов с названиями: “диплом (новый)”, “диплом (новее нового)”, “диплом (новые правки)”.

Мои статьи основаны на отличном интерактивном курсе LearnGitBranching. Но у него есть существенный недостаток, они не используют настоящий Git в процессе обучения. Из-за этого ряд важных нюансов упускается.

В моей статье будет обучение на настоящем Git. Просто повторяйте команды за мной, чтобы попрактиковаться.

Спонсор поста

Что такое VCS?

Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют откатить проект до старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Репозиторием называют хранилище вашего кода. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске. Также есть хостинги репозиториев, такие как GitHub и GitLab, которые позволяют хранить проект в интернете.

VCS позволяют нескольким разработчикам работать над одним проектом и сохранять внесённые изменения независимо друг от друга. При этом каждый участник команды видит над чем работают коллеги.

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

Установка git

Основой интерфейс для работы с Git-ом является консоль. Это не удобно использовать в работе, но некоторые проблемы решаются только через консоль.

Для установки на Windows нажимаем на кнопку ниже, скачиваем и устанавливаем.

Для Mac OS открываем терминал и пишем, если установлен Brew:

brew install git

Если Brew не установлен, то вводим эту команду.

git --version

После этого появится окно, где предложит установить Command Line Tools (CLT). Соглашаемся и ждем установки. Вместе с CLT установиться и git

Для Linux открываем терминал и вводим следующую команду.

# Debian или Ubuntu sudo apt install git # CentOS sudo yum install git

Настройка

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

Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.

git config --global user.name "ваше_имя" git config --global user.email "адрес_почты@email.com"

Инициализация репозитория

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

$ mkdir git-project $ cd git-project

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

$ git init Инициализирован пустой репозиторий Git в /home/upagge/Documents/git-project/.git/

Посмотрим, какие файлы находятся сейчас в папке git-project :

$ ls -al итого 20 drwxrwxr-x 3 upagge upagge 4096 мая 25 13:04 . drwxr-xr-x 12 upagge upagge 12288 мая 25 13:02 .. drwxrwxr-x 7 upagge upagge 4096 мая 25 13:04 .git

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

$ ls -l .git/ итого 56 drwxrwxr-x 2 upagge upagge 4096 мая 25 13:04 branches -rw-rw-r-- 1 upagge upagge 92 мая 25 13:04 config -rw-rw-r-- 1 upagge upagge 73 мая 25 13:04 description -rw-rw-r-- 1 upagge upagge 23 мая 25 13:04 HEAD drwxrwxr-x 2 upagge upagge 4096 мая 25 13:04 hooks drwxrwxr-x 2 upagge upagge 4096 мая 25 13:04 info drwxrwxr-x 4 upagge upagge 4096 мая 25 13:04 objects drwxrwxr-x 4 upagge upagge 4096 мая 25 13:04 refs

Коммиты

Коммит это одно из базовых понятий в Git. Если объяснять простым языком, то коммит это огромная копия вашего проекта в момент времени, когда этот коммит был сделан.

Но на самом деле git пытается быть лёгким и быстрым, так что он не просто слепо копирует весь проект каждый раз, а ужимает коммит в набор изменений или «дельту» между текущей версией и предыдущей. Это позволяет занимать меньше места.

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

Файлы в репозитории могут находиться в 3 различных “областях”.

Наш проект сейчас пуст. Давайте создадим наш первый файл:

echo "12345" > file.txt

На данном этапе только область “Рабочий каталог” содержит данные.

Рабочий Каталог это ваша папка с файлами, в данном случае это git-project . Две другие области сохраняют свое содержимое внутри папки .git в понятном и удобном для git формате, но не понятном для человека.

Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед тем, как сделаете коммит. На данном этапе вы можете в любой момент стереть все изменения и вернуться к последнему коммиту. Они не будут сохранены в истории git.

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

Без добавления файла в Индекс у нас не получится создать коммит, проверьте это сами с помощью комманды:

$ git commit -m "Первый коммит" На ветке main Начальный коммит Неотслеживаемые файлы: file.txt ничего не добавлено в коммит, но есть неотслеживаемые файлы

Для добавления файлов в Индекс используется следующая команда:

git add file.txt

Когда у вас много файлов, вы можете добавить их все разом git add —all .

Теперь сделаем наш первый коммит, выполнив команду git commit . Тем самым мы сохраним содержимое области Индекс как неизменяемый снимок в области HEAD . Обязательно нужно описать суть внесенных вами изменений, для этого используется флаг -m :

$ git commit -m "Первый коммит" [main (корневой коммит) 06f7fc0] Первый коммит 1 file changed, 1 insertion(+) create mode 100644 file.txt

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

Если сейчас выполнить git status , то мы не увидим никаких изменений, так как все три области одинаковые.

Теперь мы хотим внести изменения в файл и сделать новый коммит. Мы пройдём через ту же процедуру: сначала отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать зеленым цветом. Допишем в файл цифры 67890.

echo "67890" >> file.txt

Теперь посмотрим, какие изменения произошли в git:

$ git status На ветке main Изменения, которые не в индексе для коммита: (используйте «git add …», чтобы добавить файл в индекс) (используйте «git checkout -- …», чтобы отменить изменения в рабочем каталоге) изменено: file.txt нет изменений добавленных для коммита (используйте «git add» и/или «git commit -a»)

Нам подсказывают, что изменения не попадут в коммит, пока мы не сделаем git add . Выполним эту комманду чуть позже, пока добавим новый файл:

echo "qwerty" > new-file.txt

Еще раз проверяем статус репозитория:

git status На ветке main Изменения, которые не в индексе для коммита: (используйте «git add …», чтобы добавить файл в индекс) (используйте «git checkout -- …», чтобы отменить изменения в рабочем каталоге) изменено: file.txt Неотслеживаемые файлы: (используйте «git add …», чтобы добавить в то, что будет включено в коммит) new-file.txt нет изменений добавленных для коммита (используйте «git add» и/или «git commit -a»)

Новый файл появился в списке не отслеживаемых, то есть в Рабочем Каталоге . Давайте добавим в отслеживание этот файл, а так же измененный ранее.

$ git add file.txt new-file.txt $ git status На ветке main Изменения, которые будут включены в коммит: (используйте «git reset HEAD …», чтобы убрать из индекса) изменено: file.txt новый файл: new-file.txt

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

$ git commit -m "Второй коммит" [main b66f9c7] Второй коммит 2 files changed, 2 insertions(+) create mode 100644 new-file.txt

Я уже упоминал, что у коммитов есть родитель, который указывает на предыдущий коммит. Из таких цепочек складывается “ветка”. О ветках мы поговорим в следующей статье. Пока достаточно знать, что по умолчанию у нас уже есть ветка main . Эта цепочка также является нашей историей проекта, вы можете вернуться к предыдущим коммитам в любой момент.

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

Просмотр истории коммитов

Не все коммиты будете делать вы, какие-то будут делать ваши коллеги по команде, поэтому вам может понадобиться изучить историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда git log .

$ git log commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD -> main) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммит

Помимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.

Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям.

Одним из самых полезных аргументов является -p или —patch , который показывает разницу, внесенную в каждый коммит. Можно ограничить количество записей в выводе команды, используя параметр -2 :

$ git log -p -2 commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD -> main) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит diff --git a/file.txt b/file.txt index e56e15b..cbb384f 100644 --- a/file.txt +++ b/file.txt @@ -1 +1,2 @@ 12345 +67890 diff --git a/new-file.txt b/new-file.txt new file mode 100644 index 0000000..19f0805 --- /dev/null +++ b/new-file.txt @@ -0,0 +1 @@ +qwerty commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммит diff --git a/file.txt b/file.txt new file mode 100644 index 0000000..e56e15b --- /dev/null +++ b/file.txt @@ -0,0 +1 @@ +12345 

Навигация

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

Detaching HEAD

Давайте разберемся, как нам откатиться к более старой версии нашего репозитория.

У git есть указатели на коммиты, своеобразный ярлыки, которые перемещаются от коммита к коммиту. Одним из таких ярлыков-указателей является HEAD .

HEAD — это символическое имя текущего выбранного коммита. По сути это, тот коммит, над которым мы в данным момент работаем.

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

Создадим еще один файл и сделаем третий коммит:

$ echo "new new file" > three-file.txt $ git add three-file.txt $ git commit -m "Третий коммит" [main b64191a] Третий коммит 1 file changed, 1 insertion(+) create mode 100644 three-file.txt git log -2 commit b64191a1a53c7f28429042c1fe00702c15354fab (HEAD -> main) Author: uPagge Date: Tue Jun 15 21:52:20 2021 +0300 Третий коммит commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит 

Мы видим, что HEAD сейчас указывает на main , main это тоже указатель, обозначающий ветку. То есть HEAD указывает на main , который в свою очередь указывает на коммит dac5bb87a . Отделение (detaching) HEAD означает лишь присвоение его не ветке, а конкретному коммиту.

Представим, что нам надо посмотреть, как выглядел наш репозиторий после второго коммита. Для этого используем команду checkout и хэш второго коммита. Кстати, можно не указывать его целиком, достаточно первых 5 символов.

$ git checkout b66f9 Примечание: переход на «b66f9». Вы сейчас в состоянии «отделённого HEAD». Вы можете осмотреться, сделать экспериментальные изменения и закоммитить их, также вы можете отменить изменения любых коммитов в этом состоянии не затрагивая любые ветки и не переходя на них. Если вы хотите создать новую ветку и сохранить свои коммиты, то вы можете сделать это (сейчас или позже) вызвав команду checkout снова, но с параметром -b. Например: git checkout -b HEAD сейчас на b66f9c7 Второй коммит

Таким образом мы переключились на состояние второго коммита, в котором у нас еще не было файла three-file.txt , проверим это:

$ ls file.txt new-file.txt

Вызвав git log видим, что HEAD теперь указывает на второй коммит:

$ git log commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммит

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

$ git log --all commit b64191a1a53c7f28429042c1fe00702c15354fab (master) Author: uPagge Date: Tue Jun 15 21:52:20 2021 +0300 Третий коммит commit b66f9c79eb37de0beb099b04cc7f7f4979a98a83 (HEAD) Author: uPagge Date: Tue Jun 15 21:50:01 2021 +0300 Второй коммит commit 06f7fc0a337bb6105f6a792fcc93eb2dda2a4dda Author: uPagge Date: Tue Jun 15 21:48:54 2021 +0300 Первый коммит

Вернем указатель HEAD на main :

$ git checkout main Предыдущая позиция HEAD была b66f9c7 Второй коммит Переключено на ветку «main» $ ls file.txt new-file.txt three-file.txt

Относительные ссылки

Передвигаться по коммитам при помощи указания хешей неудобно. Поэтому Git поддерживает относительные ссылки. С относительными ссылками можно начать с какого-либо удобного места и двигаться от него.

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

• Перемещение на один коммит назад ^
• Перемещение на n коммитов назад ~

Для начала рассмотрим оператор каретки ^ . Когда мы добавляем его к имени указателя, Git воспринимает это как команду найти родителя выбранного коммита. Так что main^ означает “первый родитель ветки main”. main^^ означает прародитель (родитель родителя) main .

Давайте переключимся на коммит выше main :

$ git checkout main^ Примечание: переход на «main^». . HEAD сейчас на b66f9c7 Второй коммит

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

Может показаться, нужно еще раз вызвать команду git checkout main^ , чтобы попасть на первый коммит. Но это не так, указатель main остался на третьем коммите, мы сдвинули HEAD . Поэтому git checkout main^ запросит снова родителя третьего коммита.

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

$ git checkout HEAD^ Предыдущая позиция HEAD была b66f9c7 Второй коммит HEAD сейчас на 06f7fc0 Первый коммит

Вернемся на третий коммит:

$ git checkout main Предыдущая позиция HEAD была 06f7fc0 Первый коммит Переключено на ветку «main»

Оператор ~

Предположим, нужно переместиться на много шагов назад. Было бы неудобно печатать ^ несколько раз, так что Git поддерживает также оператор тильда ~ .

Опционально к тильде можно добавить количество родительских коммитов, через которые нужно пройти. Посмотрим, как это работает.

$ git checkout HEAD~2 Примечание: переход на «HEAD~2». . HEAD сейчас на 06f7fc0 Первый коммит

Мы переместились на первый коммит. Вернемся:

$ git checkout main

Заключение

Это была первая статья по обучению git. Мы установили git и научились работать с некоторыми командами для создания коммитов и навигации по ним.

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

Если все получилось, переходите к следующему уроку ��