Работа с распределенной системой контроля версий git на примере github / habr

Отмена изменений и других последствий невнимательности

В процессе работы много чего приходится отменять, отказывать и еще как-то заметать следы своих косяков, еще до того, как ваши труды полетят в продакшен, то есть пока вы возитесь в своём локальном репозитории.

Отказ от индексирования изменений

Лично моя — самая частая ошибка Сначала индексируешь всё (удобно ведь одной кнопкой), а потом вспоминаешь, что не всё-то и надо было. Или вдруг вспоминаешь, что нужно было часть текущих изменений зафиксировать отдельным коммитом. Убираем файл из области индексирования:

Игнорирование файлов, файл .gitignore

Файл .gitignore (именно так, с точкой и без расширения) и механизм игнорирования позволяют отключить от версионирования часть файлов из вашего репозитория. Это очень удобно, когда, например:

В локальном репозитории есть файл с локальными настройками или сведениями о состоянии проекта, но его смысл теряется при переходе к удалённому репозиторию. Такие файлы полезны только при работе на локальной машине, но их не надо коммитить. Пример такого файла — файл VERSION, необходимый при работе с gitsync;
В локальном репозитории вы храните дополнительные рабочие файлы проекта, которые нужны только вам, но их не нужно версионировать и делать достоянием всей команды. У меня в репозитории с правилами обмена таковыми являются файлы с описанием структуры конфигураций. Они лежат в одном месте со всем, что связано с обменами, но при этом не мешают другим разработчикам.

Файл .gitignore располагается в корневом директории репозитория, а по своей структуре — это текстовый файл, в каждой строке которого содержится имя файла, маска файла или путь к каталогу, содержимое которого следует игнорировать системе Git. В дальнейшем, при изменении таких файлов они никак не будут влиять на состояние репозитория (не появится незакоммиченных изменений).

Если вы работаете с Git из консоли, то этот файл следует создать и настроить вручную.

Следует отметить, что сам файл .gitignore тоже коммитится и версионируется. Это может сбить с толку новичка, когда, например, после получения изменений из develop система вдруг перестаёт видеть часть файлов разработчика. Или при создании новой фичи не действует игнорирование, которое только что настраивал, но настройка осталась в другой фиче, которая еще не слита в develop.

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

Отмена изменений в индексе

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

Коммиты

Так как коммиты являются основой истории версий, не будет лишним узнать о них немного больше.

Команда откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько распространённых аргументов:

позволяет написать сообщение вместе с командой, не открывая редактор. Например ;
переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить перед коммитом);
заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Несколько советов, к которым стоит прислушаться:

Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесьподробно расписано, как писать сообщения для коммитов.
(Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

Продвинутое использование: интерактивная подготовка

Вы можете с удобством управлять областью подготовленных файлов (например при фиксации нескольких небольших коммитов вместо одного большого) с помощью интерактивной консоли, которую можно запустить . В ней доступны 8 команд:

— показывает для каждого файла краткое описание того, что (не)подготовлено;
— подготавливает отслеживаемые файлы;
— убрать один или несколько файлов из подготовленной области;
— подготавливает неотслеживаемый файл;
— подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: . Можно ввести , чтобы узнать, что делает каждая команда;
— показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
— выходит из интерактивной консоли;
— показывает краткое описание каждой команды.

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

Обратите внимание, что создание патчей (подготовка только части файла) доступно не только в интерактивной консоли, но и через команду

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch
и git pull.

git fetch — забирает изменения удаленной ветки из репозитория по умолчания,
основной ветки; той, которая была использована при клонировании репозитория.
Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет
провести слияние с локальной ветку командой git merge.

Получает изменений из определенного репозитория:

Возможно также использовать синонимы для адресов, создаваемые командой git remote:

Естественно, что после оценки изменений, например, командой git diff, надо
создать коммит слияния с основной:

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

Забирает изменения и метки из определенного репозитория:

Как правило, используется сразу команда git pull.

Ветвление

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

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

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

Стандартные команды:

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

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

— привязывает текущую ветку к указанной удалённой ветке;
— аналог предыдущей команды;
— создаёт новую локальную ветку и начинает отслеживать удалённую;
— показывает локальные и отслеживаемые удалённые ветки;
— создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды . Чтобы вернуть изменения, используйте .

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

Зачем нужен Git?

Затем, чтобы не случился апокалипсис в мире разработки (и не только, но мы будем оперировать именно областью IT). Сейчас трудно представить себе мало-мальски крупное приложение, над которым работал бы один человек. За проектом всегда стоит целая команда создателей. И чтобы им всем было комфортно работать вместе, нужна распределенная система контроля версий. Это гарантия отсутствия конфликтов в коде и возможность вести разработку нескольких функций ПО, не соприкасаясь друг с другом и общим кодом.

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

Глобальный .gitignore

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

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

Например, чтобы установить в качестве глобального файла игнорирования Git, вы должны сделать следующее:

Создайте файл:
Добавьте файл в конфигурацию Git:
Откройте файл в текстовом редакторе и добавьте в него свои правила.

Глобальные правила особенно полезны для игнорирования определенных файлов, которые вы никогда не хотите фиксировать, например файлов с конфиденциальной информацией или скомпилированных исполняемых файлов.

Дополнительный этап жизненного цикла с Github

Имейте в виду, что мы изучаем жизненный цикл исключительно в Git. То есть важно отметить, что три стадии, рассмотренные выше, предназначены только для Git, а не для Github. Почему? Потому что вы можете отслеживать версии ваших файлов, используя только Git

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

Допустим, что мы работаем в командах и сотрудничаем с несколькими людьми над данным проектом. Это делает необходимым понять дополнительную стадию, связанную с Github. При работе с Github существует понятие удаленного хранилища и связанный с ним процесс, называемый Pushing the files.

Закоммитьте изменения

Достаточно об индексации. Давайте сделаем коммит того, что мы проиндексировали, в репозиторий.

Когда вы ранее использовали git commit для коммита первоначальной версии файла hello.html в репозиторий, вы включили метку -m, которая делает комментарий в командной строке. Команда commit позволит вам интерактивно редактировать комментарии для коммита. Теперь давайте это проверим.

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору.

Сделайте коммит сейчас и проверьте состояние.

Выполните:

Результат:

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору.

Сделайте коммит сейчас и проверьте состояние.

Выполните:

Результат:

Выполните:

В первой строке введите комментарий: «Added h1 tag». Сохраните файл и выйдите из редактора. Вы увидите…

Результат:

Проверьте состояние

В конце давайте еще раз проверим состояние.

Выполните:

Результат:

Рабочий каталог чистый, можете продолжить работу.

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

Возможно также использовать синонимы для адресов, создаваемые командой :

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:

git merge username-project/master

Команда сразу забирает изменения и проводит слияние с активной веткой.

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

Как правило, используется сразу команда .

git push — вносим изменения в удаленный репозиторий

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

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

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Как работать с Git

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

С Git можно работать как через командную строку, так и через графический интерфейс вроде GitHub Desktop. Хотя начинающих разработчиков командная строка может отпугнуть, её всё равно лучше изучить, ведь она предоставляет больше возможностей, чем многие инструменты с интерфейсом.

Как правило, команды Git принимают вид , где аргументом может быть путь к файлу. У команд также могут быть опции, которые обозначаются как или . Они позволяют более детально настроить действия команды. В этой статье команды будут представлены в общем виде, поэтому всё, что находится в , вам нужно будет заменить на собственные значения.

Если вы не знаете, как использовать команду, то можете открыть руководство с помощью , а если вам просто нужно напоминание, используйте или ( и эквивалентны).

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

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

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

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

Представьте, что ваш проект состоит из сотни файлов и десятков тысяч строк кода. Вы делаете какую-то задачу, в процессе меняете 15 файлов и 300 строк кода и вдруг становится понятно, что эта задача больше не актуальна. На этом моменте нужно вернуться к состоянию исходного кода, которое было до изменений. И это только один из множества вариантов событий. Другой вариант — в процессе работы над кодом стало понятно, что нужно срочно внести исправление в рабочий проект (сайт). Новую задачу в нерабочем состоянии выкладывать на сайт нельзя, а это значит, что исправление нужно вносить в ту версию кода, которая была до начала реализации новой задачи.

Самый простой вариант решения, указанных выше проблем — копирование директорий. К сожалению, такой подход обладает только недостатками. Перенос изменений из одной директории в другую возможен только полной перезаписью, так как точечные изменения отследить невозможно (только по памяти). Как только папок станет две, вы сразу начнёте путаться в них. И всё равно этот способ никак не поможет работать над кодом одновременно двум людям.

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

К счастью, эту задачу решили ещё в 80-х годах. С тех пор инструментарий сильно развился и стал использоваться повсеместно не только для кода, но и, например, для написания и перевода книг. Решением является контроль версий. Выполняется он с помощью специальных программ, которые умеют отслеживать изменения кода. Вот некоторые из многочисленных возможностей данных систем:

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

В этом руководстве мы разберём общие принципы работы подобных программ.

Процесс жизнедеятельности задачи

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

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

Напомню, что в процессе коммита изменённые файлы проходят через несколько состояний: сначала они индексируются (или собираются «в очередь» на фиксацию, add), затем производится коммит (commit) проиндексированных изменений в локальный репозиторий, и в конце выполняется отправка (push) изменений в удалённый репозиторий. Некоторые инструменты по работе с Git делают несколько или все эти операции одновременно, так что для разработчика процесс происходит быстро и не напряжно. Но в целом положение дел с вашими файлами именно такое.

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

Тут я хотел продемонстрировать еще одно преимущество работы с Git: ваш рабочий каталог — это сам git-репозиторий. Не нужно куда-то отдельно копировать обработку, чтобы потом что-то делать для фиксации версии. Достаточно сохранить ее прямо в репозитории, а всю грязную работу Git и Precommit1c выполнят за вас. Главное — правильно указать в начале текущую рабочую ветку.

О Wiki на GitHub

Wii на GitHub можно использовать в качестве сайта документации. Вот пример API Basecamp, который размещен на GitHub.

В отличие от других Wiki, создаваемый Wiki на GitHub — это собственный репозиторий, который можно клонировать и работать локально. (Если посмотреть на ссылку «Клонировать эту Wiki локально», то увидим, что это хранилище, отдельное от основного хранилища кода.) С файлами можно работать локально, и фиксировать их в хранилище Wiki. Можно расположить ссылки на вики-страницы на боковой панели.

Wiki-страницы на GitHub используют синтаксис Markdown. Для этого есть специальная версия, названная Github-flavored Markdown или GFM. Эта версия Markdown позволяет создавать таблицы, классы для блоков кода (для корректной подсветки синтаксиса) и т.д.

Поскольку с вики-файлами можно работать локально, можно использовать другие инструменты (например, генераторы статичных сайтов или даже DITA) для генерации файлов Markdown при желании. Работая локально, можно обрабатывать переиспользование, условную фильтрацию и другую логику за пределами вики-сайта GitHub. После чего можно вывести свой контент в виде файлов Markdown и зафиксировать их в своем хранилище GitHub.

Warning: Git используется только для отслеживания текстовых файлов. Не работает Git c большими двоичными файлами, такими как аудиофайлы, видеофайлы, файлы Microsoft Word или файлы Adobe PDF. Системы контроля версий действительно не справляются с такими форматами, и размер репозитория будет возрастать в геометрической прогрессии. Используя Git для управления документацией, такие файлы исключаются через файл .gitignore. Можно также исключить изображения, так как они увеличивают размер вашего репо.

Коммитим изменения

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

git commit -m "Мой первый коммит"

Указывайте сообщение, которое будет содержать полезную информацию, так как они помогают понять, что же именно было изменено в рамках данного коммита. Избегайте каких-то общих сообщений, типа “Правил баги”. Если у вас есть баг-трекер, вы можете указать сообщение типа “Поправлен баг #123”. Хорошая практика — указывать в сообщении имя ветки или улучшения. Например, “Управление активами — добавлена возможность генерировать PDF на основе актива” — понятное и доходчивое сообщение.

Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом .

Совмещение веток

После того, как мы обсудили, что такое ветки и как между ними переключаться, пора поговорить о том, как их можно совмещать после разработки. Ветку, в которую мы хотим слить изменения, будем называть основной, а ветку, из которой мы будем их сливать, — тематической. Есть два способа внесения изменений из одной ветки в другую: слияние и перемещение.

Слияние

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

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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

<<<<<<< HEAD:index.html
Everything above the ==== is the version in master.
=======
Everything below the ==== is the version in the test branch.
>>>>>>> test:index.html

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

Перемещение

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

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

Перемещение vs. слияние

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

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

Представим сценарий:

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

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

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

Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

¶ Ограничение вывода

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

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

Полезны такие опции для ограничения вывода по времени, как и . Например, следующая команда покажет список коммитов, сделанных за последние две недели:

Эта команда работает с большим количеством форматов. Вы можете указать определенную дату () или же относительную дату, например, .

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

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

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

Ветки

Ветка в Git — это простой перемещаемый указатель на один из таких коммитов. По умолчанию имя основной ветки в Git — master.

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