Следующие несколько примеров используют очень простой проект «simplegit». Чтобы клонировать проект, используйте команду:
Если вы запустите команду git log в каталоге клонированного проекта, вы увидите следующий вывод:
По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке — последние коммиты находятся вверху. Из примера можно увидеть, что данная команда перечисляет коммиты с их SHA-1 контрольными суммами, именем и электронной почтой автора, датой создания и сообщением коммита.
Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям. Рассмотрим наиболее популярные из них.
Сокращенный хеш коммита
Сокращенный хеш дерева
Сокращенный хеш родителей
Электронная почта автора
Относительная дата автора
Электронная почта коммитера
Относительная дата коммитера
Вам наверное интересно, какая же разница между автором и коммитером. Автор — это человек, изначально сделавший работу, а коммитер — это человек, который последним применил эту работу. Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника — вы как автор и основной член команды как коммитер. Более детально мы рассмотрим разницу в главе Распределенный Git.
Данный вывод будет нам очень интересен в следующей главе, где мы рассмотрим ветвление и слияние.
Мы рассмотрели только несколько простых опций для форматирования вывода с помощью команды git log — на самом деле их гораздо больше. Наиболее распространенные опции для команды git log содержит описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
Таблица 2. Наиболее распространенные опции для команды git log
Опция
Описание
Показывает патч для каждого коммита.
Показывает статистику измененных файлов для каждого коммита.
Показывает список измененных файлов после информации о коммите.
Показывает список файлов, которые добавлены/изменены/удалены.
Показывает только несколько символов SHA-1 чек-суммы вместо всех 40.
Отображает дату в относительном формате (например, «2 weeks ago») вместо стандартного формата даты.
Отображает ASCII граф с ветвлениями и историей слияний.
Показывает коммиты в альтернативном формате. Возможные варианты опций: oneline, short, full, fuller и format (с помощью последней можно указать свой формат).
Ограничение вывода
В таблице Опции для ограничения вывода команды git log вы можете увидеть эти и другие распространенные опции.
Таблица 3. Опции для ограничения вывода команды git log
Опция
Описание
Показывает только последние n коммитов.
Показывает только те коммиты, которые были сделаны после указанной даты.
Показывает только те коммиты, которые были сделаны до указанной даты.
Показывает только те коммиты, в которых запись author совпадает с указанной строкой.
Показывает только те коммиты, в которых запись committer совпадает с указанной строкой.
Показывает только коммиты, сообщение которых содержит указанную строку.
Показывает только коммиты, в которых изменение в коде повлекло за собой добавление или удаление указанной строки.
Например, если вы хотите увидеть, в каких коммитах произошли изменения в тестовых файлах в исходном коде Git в октябре 2008 года, автором которых был Junio Hamano и которые не были коммитами слияния, вы можете запустить следующую команду:
Из почти 40 000 коммитов в истории исходного кода Git, эта команда показывает только 6, которые соответствуют этим критериям.
Git для начинающих. Урок 5. История коммитов в подробностях
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Для информации
Урок частично повторяет содержание предыдущего. Но в отличие от прошлого историю коммитов мы рассмотрим намного подробнее.
История коммитов
Команда git log
За просмотр истории коммитов отвечает команда git log. В сочетании с различными параметрами эта команда выводит историю по-разному. Есть много различных вариантов и комбинаций параметров, посмотрим некоторые из них
git log, просмотр истории по умолчанию
Показывает все коммиты от новых к старым. Для каждого коммита выводится
Выводит то же, что и git log, но еще и с изменениями в файлах
Вывод коммитов в одну строку. Показывает только хэш коммита и commit message
Выводит коммиты в виде дерева, в командной строке псевдографикой. Плюс выводит список измененных файлов. К дереву коммитов мы вернемся, когда будем работать с ветками.
Сортировка и фильтрация истории
Есть множество команд, которые позволяют сортировать и фильтровать историю коммитов в командной строке. В том числе в сочетании с линуксовыми командами. Рассмотрим некоторые из них
Поиск по коммитам
Коммиты, затронувшие один файл
Поиск по автору
Поиск по диапазону дат
Комбинация команд и опций
Команды и опции git можно комбинировать и дополнять их линуксовыми командами
Какие еще есть варианты
Мы рассмотрели базовые примеры, но в документации по git log есть много различных опций. Все их рассматривать нет смысла, при необходимости изучайте документацию.
Просмотр отдельного коммита, git show
Чтобы просмотреть отдельный коммит, нужно узнать его хэш. Хэш коммита выводится в любой команде git log, с параметрами или без. Например,
Смотрим второй коммит
Выводится подробная информация о коммите:
Короткий хэш коммита
История коммитов в PhpStorm
В окне Local Changes, на вкладке Log показывается вся история коммитов, в левой половине вкладки. В списке коммитов показываются их commit message, автор и дата. Клик на нужный коммит откроет в правой части вкладки список измененных файлов. Клик на нужном файле и Ctrl/Cmd+D покажет все изменения в этом файле точно так же, как и git diff.
В тексте объяснить работу с историей в PhpStorm сложно, смотрите видеоурок.
Переключение на старый коммит, зачем это нужно
Нужно это обычно в двух случаях:
1. При неудачном деплое, когда вскрылась критичная бага. Если бага сложная и пофиксить ее быстро не удается, можно откатиться на рабочий коммит, задеплоить рабочую версию и уже потом чинить багу.
2. При отладке. Когда в код закралась бага и мы постепенно продвигаемся «назад в прошлое» и ищем, в какой момент что-то сломалось
Как переключиться на коммит в терминале
Чтобы вернуться обрано, в исходное состояние, нужно набрать
Как переключаться между коммитами в PhpStrom
Вкладка Log, правый клик на нужном коммите и Checkout Revision. Все. История коммитов будет видна по-прежнему вся, но напротив текущего коммита будет стоять значок HEAD с символом «!»
Что могу посоветовать
На этом все. В следующем уроке мы поговорим о взаимодействии с сервером и познакомимся с командами git push и git pull.
Выводим полный граф коммитов c сокращёнными хешами, ссылками на коммиты и относительной датой. Используемый формат: синий сокращённый хеш коммита, зелёная дата, белые сообщение и автор, жёлтые ссылки на коммит.
Выводим полный граф коммитов c сокращёнными хешами, ссылками на коммиты и абсолютной датой. Используемый формат: синий сокращённый хеш коммита, голубая абсолютная дата, зелёная относительная дата, жёлтые ссылки на коммит, перевод строки, белые сообщение и автор.
Выводим полный граф коммитов, отводя по одной строке на коммит.
Выводим полный граф коммитов c сортировкой по дате, отображаемой в краткой форме. Используемый формат: сокращённый хеш, дата, автор, зелёные ссылки на коммит, сообщение.
Линейный вид
Вывод списка коммитов с параметрами по умолчанию.
Выводим список коммитов и показываем diff для каждого.
Выводим список коммитов и показываем статистику по каждому.
Выводим список коммитов по одному на строчке.
Выводим список коммитов с использованием следуюещго формата: сокращённый хеш коммита, автор, относительная дата, сообщение.
Визуальный интерфейс
Если есть возможность, то всё таки коммиты приятнее изучать через специализированный интерфейс, а не из консоли. Лично я очень люблю GitExtensions:
Также удобно использовать встроенную утилиту gitk:
Полезные параметры
Все параметры команды git log не нужны, но некоторые самые полезные хорошо бы помнить. Приведу несколько примеров использования ходовых параметров.
Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!
1. Параметры для удобного просмотра лога
Вообще, в Git есть много всяких полезных параметров. Просто попробуйте выполнить man git-log чтобы посмотреть все варианты просмотра истории. Если ни один из предложенных вариантов вас не устроит, вы всегда можете воспользоваться параметром —pretty, с помощью которого можно настраивать выдачу в широких пределах.
2. Вывод актуальных изменений в файл
Далее можно использовать функцию поиска утилиты less, набрав «слеш» и введя поисковый запрос: /<<поисковый-запрос>> (используйте маленькую «n» для перехода к следующему результату поиска и большую «N» для того, чтобы вернуться к предыдущему):
3. Просмотр изменений в определённых строках файла
С помощью команды git blame filename можно определить автора последних изменений для каждой строки в файле.
Это замечательный инструмент, однако иногда бывает недостаточно информации, которую он предоставляет.
В качестве альтернативы можно использовать команду git log с флагом -L, который позволяет указать номер интересующей строки в нужном файле, и Git отобразит только те изменения, которые связаны с этой строкой.
4. Просмотр ещё не влитых в родительскую ветку изменений
Если вам приходилось работать с долгоживущими ветками, над которыми трудится много людей, то вы наверняка сталкивались с множественными вливаниями (мёржами) родительской ветки (например, master) в ветку с разрабатываемой фичей. Такие мёржи затрудняют просмотр истории изменений рабочей ветки, потому что будет сложно отличить коммиты, сделанные в родительской ветке от коммитов рабочей ветки.
5. Извлечение файла из другой ветки
Пример команды: git show some-branch:some-file.js
Иногда бывает удобно посмотреть на какой-либо файл в другой ветке, не переключаясь на неё. Это можно сделать с помощью команды git show some-branch-name:some-file-name.js, которая выведет содержимое файла в указанной ветке прямо в терминал.
А с помощью перенаправления вывода можно сохранить этот файл в указанное место на диске, например, если вы заходите открыть два файла одновременно в своём редакторе: git show some-branch-name:some-file-name.js > deleteme.js.
Примечание: если вам нужно всего лишь сравнить два файла, то можно выполнить такую команду: git diff some-branch some-filename.js
6. Пара слов о ребейзе
Ранее мы говорили о многочисленных мёржах мастера в рабочую ветку. Некоторых из них можно избежать, используя команду git rebase. Вообще, ребейз — очень мощная функция, и, пожалуй, будет лучше оставить её подробное описание для отдельного поста. Вот, например, что говорится в книге «Pro Git»:
Несмотря на все свои преимущества, у ребейза есть и свои недостатки, которые можно выразить одним предложением:
Не делайте ребейз коммитов, находящиеся вне вашего репозитория.
Если вы последуете этому совету, то всё будет хорошо. В противном случае все будут вас ненавидеть, а друзья и семья станут вас презирать.
Однако ребейза не нужно бояться, просто следует соблюдать осторожность при работе с ним.
Например, вы работаете с локальной копией ветки и сделали небольшой коммит. А в это время кто-то ещё залил в удалённую копию ветки результаты своего недельного труда. Когда вы попытаетесь запушить свои изменения, Git скажет вам, что он не может это сделать, и что вам сначала нужно сделать git pull для разрешения конфликта. Как добропорядочный человек вы так и поступите и после выполнения команды git pull в истории вашей локальной копии ветки получится вот такой вот коммит, сгенерированный автоматически: «Merge remote-tracking branch ‘origin/master’».
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
Этот совет очень простой. Допустим, вы сделали изменения, закоммитили их, а потом обнаружили опечатку. Вы можете сделать новый коммит с описанием «исправление опечатка», но есть вариант получше.
Если вы ещё не запушили изменения в удалённую ветку, то можно сделать вот так вот:
9. Три состояния в Git и переключение между ними
Как вы, наверное, уже знаете, файл в Git может находится в одном из трёх состояний:
(На самом деле есть ещё, как минимум, статус untracked — файл не добавлен в репозиторий — прим. перев.).
Очевидно, что команда git status не покажет вам уже закоммиченные файлы, для их просмотра следует использовать команду git log.
Есть ещё несколько команд для переключения состояния файлов.
Сброс состояния файлов
Сброс позволяет откатиться на определённую версию в истории изменений Git. Всего есть три вида сброса:
Поналачу эта информация может показаться бесполезной, однако, когда вы начнёте работать с разными версиями файлов, она вам очень пригодится. Например, я для себя выделил вот такие сценарии использования этих команд:
Выгрузка отдельных файлов
Также можно забирать разные версии файла из других коммитов или веток: git checkout some-branch-name file-name.js и git checkout <> file-name.js.
Обратите внимание, что выгруженные файлы будут находиться в состоянии «Staged for commit», и чтобы убрать их из индекса для коммита нужно будет использовать команду git reset HEAD file-name.js. Для возврата в исходное состояние просто наберите git checkout file-name.js ещё раз.
10. Мягкая отмена коммитов
Это очень удобная команда на тот случай, если вам нужно откатить последние пару коммитов, покопаться в изменениях и найти проблемное место.
Обычный git revert автоматически закоммитит те изменения, которые откатили, запросив у вас примечание к новому коммиту отката. Флаг «-n» говорит гиту, чтобы тот не переживал по поводу срочного коммита новых изменений, ведь мы хотим просто посмотреть на них.
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
Моя любимая программа для сравнения файлов в графическом интерфейсе — Meld. Я влюбился в неё ещё со времён Linux, и с тех пор она всегда со мной.
Я, кстати, не пытаюсь пропагандировать Meld. Скорее всего, у вас уже есть любимая программа для сравнения файлов, и, вероятнее всего, она умеет работать с Git, как для сравнения, так и для разрешения конфликтов. Просто запустите следующие команды, заменив «meld» на свою любимую утилиту:
После этого всё, что вам нужно — запустить команду git difftool some-file.js для просмотра изменений в соответствующей программе вместо консоли.
12. Игнорирование пробелов
Если вам когда-нибудь приходилось менять отступы или переформатировать файлы, то вы наверняка сталкивались с тем, что, по мнению команды git blame, вы теперь ответственны за все изменения в этих файлах.
К счастью, Git достаточно умён, чтобы понимать, что к чему. Вы можете запускать многие команды (такие, как git diff, git blame и т.д.) с флагом «-w» и Git будет просто игнорировать все изменения, связанные с пробельными символами (пробел, табуляция и другие).
13. Добавление определённых изменений из файла
Кто-то из разработчиков Git явно неравнодушен к флагу «-p«, поскольку обычно он добавляет очень удобные штуки к различным командам.
В случае с командой git add, этот флаг позволяет в интерактивном режиме выбрать, какие именно изменения из файла вы хотите закоммитить. Таким образом, вы можете более логично огранизовать последовательность своих коммитов, чтобы их проще было смотреть.
14. Поиск и удаление старых веток
Зачастую проекты обрастают большим количеством веток в удалённом репозитории, некоторые из них остаются там даже после того, как они были вмёржены в основную ветку (master). Если вы такой же фанат чистоты (по крайней мере во всём, что касается кода), как и я, вас наверняка раздражает наличие подобных веток.
Можно изощриться и вывести списки всех удалённых веток, комментарии к последним коммитам в них и дату последних изменений:
К сожалению, насколько я знаю, нет более лёгкого способа получить список смёрженных веток. Так что здесь придётся сравнивать два списка или писать для этого скрипт.
15. Откладывание изменений определённых файлов
Если вы ещё не знаете, что делает команда git stash, то она просто кладёт все незакоммиченные изменения в специальный стек Git. Потом вы в любой момент можете выполнить git stash pop и применить все эти изменения назад. Вы так же можете посмотреть список всех сохранённых состояний в стеке с помощью команды git stash list, для более подробной информации посмотрите справку: man git-stash.
У команды git stash есть один недостаток: она откладывает сразу все файлы, а иногда бывает удобно отложить только некоторые файлы, а остальные оставить и продолжить работать с ними.
Помните магический ключ «-p«? У команды git stash он тоже есть, и, как вы уже, наверное, догадались, этот при использовании этого ключа Git предложит вам выбрать те изменения, которые нужно отложить.
Обязательно попробуйте нажать «?«, чтобы посмотреть список всех возможных опций.
Есть ещё один способ отложить только те файлы, которые нужно:
16. Хорошие примечания к коммиту
По этой теме можно посоветовать замечательную статью «Как писать примечания к коммитам».
Здесь же я хочу особо подчеркнуть одно важное правило: хорошее примечание к коммиту должно заканчивать следующее предложение: «После применения данный коммит << текст вашего примечания >>». Например:
17. Автодополнения команд Git
Для некоторых операционных систем (например, Ubuntu), автодополнение для Git в шелле включено по умолчанию. Если в вашей операционной системе это не так (а в Mac OS X это не так), вы легко можете включить автодополнение.
18. Создание алиасов для часто используемых команд
TL;DR: используйте алиасы Git или bash для наиболее часто используемых команд Git.
Лучше всего работать с Git через командную строку. А лучший способ освоиться с командной строкой — каждый раз делать всё в полном объёме (набирать длинные команды). Однако рано или поздно приходит желание создать более короткие и удобные алиасы, чтобы не вводить каждый раз одни и те же команды.
Git имеет встроенную систему алиасов, например, если вы выполните следующую команду:
19. Быстрый поиск плохого коммита
Пример команды: git bisect
Команда git bisect использует принцип «разделяй и властвуй» для поиска плохого коммита в большой истории изменений.
Представьте, что вы вернулись из продолжительного отпуска. Вы забираете последнюю версию проекта из удалённого репозитория и обнаруживаете, что та фича, над которой вы работали перед самым отпуском, теперь не работает. Вы проверяете последний сделанный вами коммит — там всё работает. Однако за время вашего отпуска в проекте появились сотни других коммитов, и вы представления не имеете, который из них оказался плохим и сломал вашу фичу.
Наверняка вы будете пытаться найти баг, поломавший вашу фичу и с помощью команды git blame на злополучном коммите найти человека, которому можно предъявить претензию. Но если баг трудно обнаружить, вы можете попробовать изучить историю изменений, в надежде отыскать плохой коммит.
Вот второй вариант — это именно тот случай, когда пригождается команда git bisect. Она позволяет вам найти плохой коммит в кратчайшие сроки.
Так что же делает git bisect?
После того, как вы укажете коммит, в котором ничего не работает («плохой» коммит) и коммит, в котором всё работает («хороший» коммит), git bisect разделит все коммиты, которые располагаются между ними пополам, переключится в новую (безымянную) ветку на этом срединном коммите и позволит вам проверить, работает ли в нём ваша фича.
Предположим, в этом «срединный» коммите всё работает. Тогда вы говорите об этом гиту с помощью команды git bisect good и у вас останется только половина всех коммитов для поиска того самого, поломавшего всё.
После выполнения этой команды Git разделит оставшиеся коммиты пополам и снова переключится в безымянную ветку на новом срединном коммите, позволив вам протестировать работоспособность вашей фичи. И так далее, пока вы не обнаружите тот самый «плохой» коммит.
Благодаря тому, что вы каждый раз делите группу коммитов пополам, для обнаружения искомого вам потребуется примерно log(n) итераций (см. Сложность алгоритма).
Список команд, которые понадобятся вам для работы с git bisect:
Данную процедуру можно автоматизировать с помощью скрипта.
Следующие несколько примеров используют очень простой проект « simplegit ». Чтобы клонировать этот проект, используйте команду:
Если вы запустите команду git log в каталоге клонированного проекта, вы увидите следующий вывод:
По умолчанию (без аргументов) git log перечисляет коммиты, сделанные в репозитории в обратном к хронологическому порядке – последние коммиты находятся вверху. Из примера можно увидеть, что данная команда перечисляет коммиты с их контрольными суммами SHA-1, именем и электронной почтой автора, датой создания и сообщением коммита.
Команда git log имеет очень большое количество опций для поиска коммитов по разным критериям. Рассмотрим наиболее популярные из них.
В таблице ниже показаны наиболее полезные опции для изменения формата.
Вам наверное интересно, какая же разница между автором и коммитером. Автор – это человек, изначально сделавший работу, а коммитер – это человек, который последним применил эту работу. Другими словами, если вы создадите патч для какого-то проекта, а один из основных членов команды этого проекта применит этот патч, вы оба получите статус участника – вы как автор, а основной член команды как коммитер. Более детально мы рассмотрим разницу в главе «Распределенный Git».
Данный вывод будет нам очень интересен в следующей главе, где мы рассмотрим ветвление и слияние.
Мы рассмотрели только несколько простых опций для форматирования вывода команды git log – на самом деле их гораздо больше. Таблица 2, приведенная ниже, содержит описание как уже рассмотренных, так и нескольких новых опций, которые могут быть полезными в зависимости от нужного формата вывода.
Ограничение вывода
Примечание
В таблице 3 вы можете увидеть эти и другие распространенные опции.
Например, если вы хотите увидеть, в каких коммитах произошли изменения в тестовых файлах в исходном коде Git в октябре 2008 года, автором которых был Junio Hamano, и которые не были коммитами слияния, вы можете запустить следующую команду:
Из почти 40 000 коммитов в истории исходного кода Git, эта команда показывает только 6, которые соответствуют этим критериям.
