Что делает команда git log
Перейти к содержимому

Что делает команда git log

  • автор:

Что делает команда git log

Команда git log может показать список коммитов. Сама по себе она показывает все коммиты достижимые из родительского коммита; но вы можете также сделать более определенный запрос:

$ git log v2.5.. # коммиты с (но не дистижимые) v2.5 $ git log test..master # коммит достижимый из ветки master но не из test $ git log master..test # коммит достижимый из ветки test но не из master $ git log master. test # коммит достижимый или из test или master, но не # из обоих $ git log --since="2 weeks ago" # коммиты начиная с 2 недель назад $ git log Makefile # коммиты которые модифицировали Makefile $ git log fs/ # коммиты которые модифицировали любой из файлов в # поддиректории fs/ $ git log -S'foo()' # коммиты которые добавили или удалили любые # файловые данные совпадающие со строкой 'foo()' $ git log --no-merges # не показывать коммиты слияния 

Конечно вы можете комбинировать их; следующая команда найдет коммиты начиная с v2.5 которые затрагивают файл Makefile или любой файл в директории fs/:

$ git log v2.5.. Makefile fs/ 

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

commit f491239170cb1463c7c3cd970862d6de636ba787 Author: Matt McCutchen Date: Thu Aug 14 13:37:41 2008 -0400 git format-patch documentation: clarify what --cover-letter does commit 7950659dc9ef7f2b50b18010622299c508bfdfc3 Author: Eric Raible Date: Thu Aug 14 10:12:54 2008 -0700 bash completion: 'git apply' should use 'fix' not 'strip' Bring completion up to date with the man page. 

Вы также можете попросить git log показать патчи:

$ git log -p commit da9973c6f9600d90e64aac647f3ed22dfd692f70 Author: Robert Schiele Date: Mon Aug 18 16:17:04 2008 +0200 adapt git-cvsserver manpage to dash-free syntax diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt index c2d3c90..785779e 100644 --- a/Documentation/git-cvsserver.txt +++ b/Documentation/git-cvsserver.txt @@ -11,7 +11,7 @@ SYNOPSIS SSH: [verse] -export CVS_SERVER=git-cvsserver +export CVS_SERVER="git cvsserver" 'cvs' -d :ext:user@server/path/repo.git co pserver (/etc/inetd.conf): 

Статистика в логах

Если вы передадите параметр —stat в ‘git log’, он покажет вам которые файлы изменились в этом коммите и как много строк кода было добавлено и удалено из каждого из них.

$ git log --stat commit dba9194a49452b5f093b96872e19c91b50e526aa Author: Junio C Hamano Date: Sun Aug 17 15:44:11 2008 -0700 Start 1.6.0.X maintenance series Documentation/RelNotes-1.6.0.1.txt | 15 +++++++++++++++ RelNotes | 2 +- 2 files changed, 16 insertions(+), 1 deletions(-) 

Форматирование вывода log

Вы можете форматировать вывод log так как это удобно. Параметр ‘—pretty’ может принимать множество предопределенных значений, таких как ‘oneline’ (в одну линию):

$ git log --pretty=oneline a6b444f570558a5f31ab508dc2a24dc34773825f dammit, this is the second time this has reverted 49d77f72783e4e9f12d1bbcacc45e7a15c800240 modified index to create refs/heads if it is not 9764edd90cf9a423c9698a2f1e814f16f0111238 Add diff-lcs dependency e1ba1e3ca83d53a2f16b39c453fad33380f8d1cc Add dependency for Open4 0f87b4d9020fff756c18323106b3fd4e2f422135 merged recent changes: * accepts relative alt pat f0ce7d5979dfb0f415799d086e14a8d2f9653300 updated the Manifest file 

или вы можете получить ‘short’ (кратко) форматирование:

$ git log --pretty=short commit a6b444f570558a5f31ab508dc2a24dc34773825f Author: Scott Chacon dammit, this is the second time this has reverted commit 49d77f72783e4e9f12d1bbcacc45e7a15c800240 Author: Scott Chacon modified index to create refs/heads if it is not there commit 9764edd90cf9a423c9698a2f1e814f16f0111238 Author: Hans Engel Add diff-lcs dependency 

Далее список возможных вариантов ‘medium’, ‘full’, ‘fuller’, ’email’ или ‘raw’. Тут лучше поэкспериментировать, чтобы выяснить какой наиболее вам подходит. Если ни один из них не удовалетворяет вашим потребностям вы можете создать свой собственный формат задав параметр след.образом ‘—pretty=format’ (просмотрите документацию git log чтобы узнать все форматирующие параметры).

$ git log --pretty=format:'%h was %an, %ar, message: %s' a6b444f was Scott Chacon, 5 days ago, message: dammit, this is the second time this has re 49d77f7 was Scott Chacon, 8 days ago, message: modified index to create refs/heads if it i 9764edd was Hans Engel, 11 days ago, message: Add diff-lcs dependency e1ba1e3 was Hans Engel, 11 days ago, message: Add dependency for Open4 0f87b4d was Scott Chacon, 12 days ago, message: merged recent changes: 

Другая интересная вещь которую вы можете сделать — это визуализировать граф коммитов ипользуя параметр ‘—graph’, след.образом:

$ git log --pretty=format:'%h : %s' --graph * 2d3acf9 : ignore errors from SIGCHLD on trap * 5e3ee11 : Merge branch 'master' of git://github.com/dustin/grit |\ | * 420eac9 : Added a method for getting the current branch. * | 30e367c : timeout code and tests * | 5a09431 : add timeout protection to grit * | e1193f8 : support for heads with slashes in them |/ * d6016bc : require time for xmlschema 

Это даст вас очень легкое для восприятия ASCII представление истории коммитов.

Упорядочивание Log

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

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

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

Как бы там ни было, вы можете определить ‘—topo-order’, который выведет коммиты в хронологическом порядке (т.е. коммиты потомки будут выведены перед их родителями). Если мы просмотрим git log для репозитария Grit в —topo-order, то увидим что все линии разработки сгруппированы вместе.

$ git log --pretty=format:'%h : %s' --topo-order --graph * 4a904d7 : Merge branch 'idx2' |\ | * dfeffce : merged in bryces changes and fixed some testing issues | |\ | | * 23f4ecf : Clarify how to get a full count out of Repo#commits | | * 9d6d250 : Appropriate time-zone test fix from halorgium | | |\ | | | * cec36f7 : Fix the to_hash test to run in US/Pacific time | | * | decfe7b : fixed manifest and grit.rb to make correct gemspec | | * | cd27d57 : added lib/grit/commit_stats.rb to the big list o' files | | * | 823a9d9 : cleared out errors by adding in Grit::Git#run method | | * | 4eb3bf0 : resolved merge conflicts, hopefully amicably | | |\ \ | | | * | d065e76 : empty commit to push project to runcoderun | | | * | 3fa3284 : whitespace | | | * | d01cffd : whitespace | | | * | 7c74272 : oops, update version here too | | | * | 13f8cc3 : push 0.8.3 | | | * | 06bae5a : capture stderr and log it if debug is true when running commands | | | * | 0b5bedf : update history | | | * | d40e1f0 : some docs | | | * | ef8a23c : update gemspec to include the newly added files to manifest | | | * | 15dd347 : add missing files to manifest; add grit test | | | * | 3dabb6a : allow sending debug messages to a user defined logger if provided; tes | | | * | eac1c37 : pull out the date in this assertion and compare as xmlschemaw, to avoi | | | * | 0a7d387 : Removed debug print. | | | * | 4d6b69c : Fixed to close opened file description. 

Вы можете также использовать ‘—date-order’, который изначально упорядочивает коммиты по дате коммита. Этот параметр похож на —topo-order в том смысле что он располагает родителей позади потомков, но тем не менее вывод упорядочен по времени коммита. Вы можете видеть что линии разработки не сгруппированы здесь вместе, так что они скачут вокруг в процессе паралельной разработки:

$ git log --pretty=format:'%h : %s' --date-order --graph * 4a904d7 : Merge branch 'idx2' |\ * | 81a3e0d : updated packfile code to recognize index v2 | * dfeffce : merged in bryces changes and fixed some testing issues | |\ | * | c615d80 : fixed a log issue |/ / | * 23f4ecf : Clarify how to get a full count out of Repo#commits | * 9d6d250 : Appropriate time-zone test fix from halorgium | |\ | * | decfe7b : fixed manifest and grit.rb to make correct gemspec | * | cd27d57 : added lib/grit/commit_stats.rb to the big list o' file | * | 823a9d9 : cleared out errors by adding in Grit::Git#run method | * | 4eb3bf0 : resolved merge conflicts, hopefully amicably | |\ \ | * | | ba23640 : Fix CommitDb errors in test (was this the right fix? | * | | 4d8873e : test_commit no longer fails if you're not in PDT | * | | b3285ad : Use the appropriate method to find a first occurrenc | * | | 44dda6c : more cleanly accept separate options for initializin | * | | 839ba9f : needed to be able to ask Repo.new to work with a bar | | * | d065e76 : empty commit to push project to runcoderun * | | | 791ec6b : updated grit gemspec * | | | 756a947 : including code from github updates | | * | 3fa3284 : whitespace | | * | d01cffd : whitespace | * | | a0e4a3d : updated grit gemspec | * | | 7569d0d : including code from github updates 

В заключении, вы можете изменить порядок вывода на обратный используя параметр ‘—reverse’.

This book is maintained by Scott Chacon, and hosting is donated by GitHub.
Please email me at schacon@gmail.com with patches, suggestions and comments.

Git для начинающих. Урок 5.
История коммитов в подробностях

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

Для информации

Урок частично повторяет содержание предыдущего. Но в отличие от прошлого историю коммитов мы рассмотрим намного подробнее.

История коммитов

Сохранение истории изменений или история коммитов — одна из самых важных частей git. В истории сохраняются все коммиты, по которым можно посмотреть автора коммита, commit message, дату коммита и его хэш. А также можно увидеть измененные файлы и изменения в каждом файле. То есть git хранит буквально все, от самого начала проекта.

Команда git log

За просмотр истории коммитов отвечает команда git log. В сочетании с различными параметрами эта команда выводит историю по-разному. Есть много различных вариантов и комбинаций параметров, посмотрим некоторые из них

git log, просмотр истории по умолчанию

 $ git log 

Показывает все коммиты от новых к старым. Для каждого коммита выводится

  • хэш
  • автор
  • дата
  • сообщение (commit message)

git log -p, расширенный вывод истории

 $ git log -p 

Выводит то же, что и git log, но еще и с изменениями в файлах

git log —oneline, короткая запись

 $ git log --oneline 

Вывод коммитов в одну строку. Показывает только хэш коммита и commit message

git log —stat —graph, история в виде дерева

 $ git log --stat --graph 

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

Сортировка и фильтрация истории

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

Поиск по коммитам

Команда grep — мощный инструмент, который помогает работать в том числе и с git. Например, искать по коммитам

 git log --oneline | grep revert # поиск упоминания revert git log --oneline | grep -i revert # независимо от регистра 

Коммиты, затронувшие один файл

 git log index.html 

Поиск по автору

 git log --author webdevkin 

В опции —author можно указать имя или email, необязательно целиком, можно только часть.

Поиск по диапазону дат

Опции —after и —before задают начальную и конечную даты коммитов

 git log --after='2020-03-09 15:30' --before='2020-03-09 16:00' 

Комбинация команд и опций

Команды и опции git можно комбинировать и дополнять их линуксовыми командами

 git log --author=webdevkin --oneline | grep footer # все коммиты от автора, в которых упоминается footer git log --oneline | wc -l # количество коммитов 

Какие еще есть варианты

Мы рассмотрели базовые примеры, но в документации по git log есть много различных опций. Все их рассматривать нет смысла, при необходимости изучайте документацию.

 git log --help 

Просмотр отдельного коммита, git show

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

 $ git log --oneline 7b7d7fa Fixed footer 26812f9 Revert "Fixed footer" 0f90ae7 Revert "Fixed styles" . a1f3c45 Added footer a65aa43 Added new block students to main page 0b90433 Initial commit 

Смотрим второй коммит

 $ git show 43f6afc 

Выводится подробная информация о коммите:

  • хэш
  • автор
  • дата
  • commit message
  • список измененных файлов
  • изменения в каждом файле

Короткий хэш коммита

Хэш коммита 40-символьный, но можно использовать короткую запись — первые 7 символов хэша. Команда git log —oneline выводит именно короткий хэш. Для других операций с коммитами достаточно использовать первые 4 символа. Например, 3 команды ниже покажут содержимое одного и того же коммита

 $ git show 051f75475cb1dca3cd08c1c7367a3308671ccf7b $ git show 051f754 $ git show 051f 

История коммитов в PhpStorm

В окне Local Changes, на вкладке Log показывается вся история коммитов, в левой половине вкладки. В списке коммитов показываются их commit message, автор и дата. Клик на нужный коммит откроет в правой части вкладки список измененных файлов. Клик на нужном файле и Ctrl/Cmd+D покажет все изменения в этом файле точно так же, как и git diff.

В тексте объяснить работу с историей в PhpStorm сложно, смотрите видеоурок.

Переключение на старый коммит, зачем это нужно

Нужно это обычно в двух случаях:

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

2. При отладке. Когда в код закралась бага и мы постепенно продвигаемся «назад в прошлое» и ищем, в какой момент что-то сломалось

Как переключиться на коммит в терминале

Первое — узнать хэш нужного коммита. Например, имеем такую историю

 $ git log --oneline 7b7d7fa Fixed footer 26812f9 Revert "Fixed footer" 0f90ae7 Revert "Fixed styles" . a1f3c45 Added footer a65aa43 Added new block students to main page 0b90433 Initial commit 

Хотим переключиться на предпоследний коммит. Коммиты идут в порядке убывания, поэтому нам нужен второй сверху — 26812f9. Переключаемся на него командой

 $ git checkout 26812f9 

Все, вернулись в прошлое. Проверим историю, теперь коммит, на который мы переключились — последний

 $ git log --oneline 26812f9 Revert "Fixed footer" 0f90ae7 Revert "Fixed styles" . a1f3c45 Added footer a65aa43 Added new block students to main page 0b90433 Initial commit 

Уйдем еще дальше, переключимся на первый коммит. Так как коммиты упорядочиваются по убыванию даты, то первый коммит — это последний в списке — 0b90433 Initial commit

 $ git checkout 0b90433 
 $ git log --oneline 0b90433 Initial commit 

Чтобы вернуться обрано, в исходное состояние, нужно набрать

 $ git checkout master 

master — это ветка, в которой мы работаем по умолчанию. О ветках поговорим через пару уроков

Как переключаться между коммитами в PhpStrom

Вкладка Log, правый клик на нужном коммите и Checkout Revision. Все. История коммитов будет видна по-прежнему вся, но напротив текущего коммита будет стоять значок HEAD с символом «!»

Как вернуться обратно? В правом нижем угле PhpStorm есть пункт git: , кликаем на него, выбираем Local Branches — master — checkout. Значок «!» пропадет — мы вернулись в исходное состояние

Что могу посоветовать

  • как и git diff, историю коммитов git log удобнее смотреть в PhpStorm
  • в команде git log есть множество вариантов сортировки и фильтрации
  • сочетание git log с простыми линуксовыми командами дает хороший эффект. Обычный grep — очень хороший помощник
  • PhpStorm предоставляет удобные возможности по фильтрации коммитов. Можно искать коммиты по commit message, по автору, дате и по папкам, в которых происходили изменения
  • перемещайтесь по истории осторожно, не забывайте возвращаться в исходное состояние

На этом все. В следующем уроке мы поговорим о взаимодействии с сервером и познакомимся с командами git push и git pull.

Спасибо за внимание и до встречи!

Все уроки курса

  • Вводный урок
  • 1. Установка и базовая настройка git
  • 2. Создание и клонирование репозитория git
  • 3. Делаем первые изменения, git status и git diff
  • 4. Коммиты и история коммитов, git commit, git log и git show
  • 5. Подробнее об истории коммитов. Путешествие по истории
  • 6. Работа с сервером, git push и git pull
  • 7. Ветки — главная фишка git, git branch и git checkout
  • 8. Работа с ветками на сервере, git fetch
  • 9. Слияния или мерджи веток, git merge
  • 10. Конфликты и их разрешение
  • Платная часть курса. Презентация
  • * 11. Работа с gitignore и git exclude
  • * 12. Буфер обмена git, git stash
  • * 13. Копирование коммитов, git cherry-pick
  • * 14. Отмена и редактирование последнего коммита
  • * 15. Отмена произвольного коммита, git revert
  • 16. Склеивание коммитов, git rebase —interactive и git reflog
  • * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
  • * 18. Работа с git rebase. Отличия от merge
  • * 19. Что такое git push —force и как с ним работать
  • * 20. Ищем баги с помощью git, git bisect
  • * 21. Как и зачем работать с тегами git
  • * 22. Процессы: github flow и git flow
  • * 23. Псевдонимы в git
  • 24. Мердж-реквесты
  • * 25. Форки

Git. Коротко о главном

Привет, Хабр! Меня зовут Егор, я занимаюсь разработкой мобильных приложений на Flutter. Это моя первая работа в сфере IT, и как подобает начинающим, я столкнулся с проблемой изучения систем контроля версий. В данной публикации я хочу поделиться приобретенными знаниями и подробно рассмотреть одну из таких систем, а именно Git. Итак, начнем.

“Whoah, I’ve just read this quick tuto about git and oh my god it is cool. I feel now super comfortable using it, and I’m not afraid at all to break something.” — said no one ever.

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

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

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

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

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

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

1. Централизованные системы контроля версий;

2. Распределенные системы контроля версий.

Централизованная система контроля версий — это система, при которой репозиторий проекта хранится на сервере и вносить изменения вы можете непосредственно только в этот репозиторий при помощи специальных клиентских приложений. Среди таких систем можно выделить: ClearCase, TFVC, SVN.

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

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

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

Установка Git

Прежде чем мы продолжим, вам необходимо установить Git.

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

# Если вы используете менеджер пакетов HomeBrew, # Вы можете выполнить следующую команду: brew install git # В противном случае вам достаточно ввести: git --version # После чего вам будет предложено установить Git 
  • Windows. Перейдите по ссылке и скачайте Git соответствующий архитектуре вашего процессора (32 или 64-bit) и установите его.
  • Linux. Перейдите по ссылке для более подробной инструкции.
# Установка на Linux зависит от дистрибутива который вы используете # Debian/Ubuntu apt-get install git # Fedora yum install git

Структура директории .git/

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

Ее необходимо ввести в корне вашего проекта. Это создаст в текущем каталоге новый подкаталог .git со следующим содержанием:

Структура директории .git

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

В данном файле содержатся настройки Git репозитория. Например, здесь можно хранить email и имя пользователя.

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

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

4. info — exclude

Каталог info содержит файл exclude, в котором можно указывать любые файлы, и Git не станет добавлять их в свою историю. Это почти то же самое что и .gitingnore (возможно вы сталкивались с ним. Его можно найти в корневом каталоге вашего проекта), за тем исключением, что exclude не сохраняется в истории проекта, и вы не сможете им поделиться с другими.

Каталог refs хранит в себе копию ссылок на объекты коммитов в локальных и удаленных ветках.

Каталог logs хранит в себе историю проекта для всех веток в вашем проекте.

Каталог objects хранит в себе BLOB объекты, каждый из которых проиндексирован уникальным SHA.

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

Файл содержит ссылку на текущую ветку, в которой вы работаете

Каждый раз во время слияния в этот файл попадает SHA ветки, с которой проводилось слияние

Файл хранит в себе ссылки в виде SHA на ветки, которые участвовали в git fetch

Файл хранит в себе ссылки в виде SHA на ветки, которые участвовали в git merge

Файл содержит в себе последнее введенное вами сообщение коммита

Самые распространенные команды в Git.

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

1. Внести изменения в проект;

2. Добавить изменения в индекс(staging area) — git add (таким образом вы сообщаете Git какие именно изменения должны быть занесены в историю.)

2. Закоммитить изменения — git commit (сохранить изменения в историю проекта)

3. Запушить — git push (отправить результаты работы на удаленный сервер, чтобы другие разработчики тоже имели к ним доступ)

Итак, разберемся в этом подробнее. Проинициализировав Git репозиторий, вы начинаете вносить какие-то изменения в проект. Предположим, что вы создали файл `hello_world.txt` и работаете над его редактированием.

Введем git status и увидим следующее:

On branch master No commits yet Untracked files: (use "git add . " to include in what will be committed) hello_world.txt

Команда git status отображает состояние директории и индекса(staging area). Это позволяет определить, какие файлы в проекте отслеживаются Git, а также какие изменения будут включены в следующий коммит.

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

use “git add . ” to include in what will be committed

git add hello_world.txt

On branch master No commits yet Changes to be commited: (use "git rm --cached . " to unstage) new file: hello_world.txt

Файл добавлен в индекс. Теперь можно закоммитить внесенные изменения и оставить небольшое описание. Делается это командой:

git commit -m ‘first commit

Готово! Мы сделали наш первый коммит! Далее добавим в наш файл строку “Hello, World!”, и снова проверим git status:

On branch master Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) no changes added to commit (use "git add" and/or "git commit -a")

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

Что ж, мы научились записывать и хранить изменения на своей машине, теперь нам нужно отправить версию нашей истории на удаленный сервер. В данном примере я воспользуюсь репозиторием на GitHub.

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

Далее необходимо добавить удаленный репозиторий в Git:

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

git remote add origin https://github.com/user/hello_world.git

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

Осталось дело за малым — отправить результат нашей работы в репозиторий. Делается это следующим образом:

git push origin

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

Работа с историей

Итак, как записывать, сохранять и отправлять изменения в удаленное хранилище мы разобрались.

Настало время поговорить о том, как управлять историей проекта. А именно как просматривать изменения и как откатить проект до определенной точки.

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

  • git log
  • git show
  • git reflog
  • git reset
  • git log

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

Если ввести git log без каких либо параметров, выглядит это примерно так:

commit 957e1132f57d83§dbd402faf3c858cf5ba8b335f (HEAD -> master) Author: egor Date: Fri Jul 16 13:25:21 1021 +0300 fourth commit commit ekd53dkcld4dkf334r3r3sefio5dk6kfl54dkf53 Author: egor Date: Fri Jul 16 13:22:25 2021 +0300 third commit commit dslf4453lk34jk34k3h5g34u6m5n75j7kj3l345k Date: Fri Jul 16 13:22:27 2021 +0300 second commit commit h4k4o5jk2lhkl234jkl6nkg6j4lh4gjbh6ll45k4 Author: egor Date: Fri Jul 16 13:21:32 2021 +0300 first commit

git log имеет огромное множество дополнительных параметров, которые будут влиять на вывод в консоль. Вам предоставляется выбор на любой вкус.

Хотите просмотреть последние три коммита? Пожалуйста:

commit ekd53dkcld4dkf334r3r3sefio5dk6kfl54dkf53 Author: egor Date: Fri Jul 16 13:22:25 2021 +0300 third commit commit dslf4453lk34jk34k3h5g34u6m5n75j7kj3l345k Date: Fri Jul 16 13:22:27 2021 +0300 second commit commit h4k4o5jk2lhkl234jkl6nkg6j4lh4gjbh6ll45k4 Author: egor Date: Fri Jul 16 13:21:32 2021 +0300 first commit

Есть необходимость вывести все в одну линию? Запросто:

git log —oneline

957e113 (HEAD -> main) fourth commit ekd53dk third commit dslf445 second commit h4k4o5j first commit

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

Команда git show используется для отображения полной информации о любом объекте в Git, будь то коммит или ветка. По умолчанию git show отображает информацию коммита, на который в данный момент времени указывает HEAD.

Для удобства работы git show оснащен рядом дополнительных параметров, некоторые из них мы рассмотрим ниже.

Итак, если ввести git show , мы получим следующий результат:

commit 957e1132f57d83§dbd402faf3c858cf5ba8b335f (HEAD -> master) Author: egor Date: Fri Jul 16 13:25:21 1021 +0300 fourth commit diff --git a/hello_world.txt b/hello_world.txt index b402110..d49b5d7 10044 --- a/hello_world.txt +++ b/hello_world.txt @@ -1,2 +1,3 @@ Hello world! Bye, bye! +See you soon!

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

Мы также можем вывести диапазон из указанных коммитов. Диапазон указывается полуоткрытым интервалом, содержащим id коммитов, не включая первый элемент. Выглядит это следующим образом:

git show 349de9d..957e113

commit 957e1132f57d83§dbd402faf3c858cf5ba8b335f (HEAD -> master) Author: egor Date: Fri Jul 16 13:25:21 1021 +0300 fourth commit diff --git a/hello_world.txt b/hello_world.txt index b402110..d49b5d7 10044 --- a/hello_world.txt +++ b/hello_world.txt @@ -1,2 +1,3 @@ Hello world! Bye, bye! +See you soon! commit ekd53dkcld4dkf334r3r3sefio5dk6kfl54dkf53 Author: egor Date: Fri Jul 16 13:22:25 2021 +0300 third commit diff --git a/hello_world.txt b/hello_world.txt index cd08755..b402110 100644 --- a/hello_world.txt +++ b/hello_world.txt @@ -1 +1,2 @@ Hello world! +Bye, bye!

Для более лаконичного вывода, можно воспользоваться командой:

git show —oneline

957e113 (HEAD -> master) fourth commit diff --git a/hello_world.txt b/hello_world.txt index b402110..d49b5d7 10044 --- a/hello_world.txt +++ b/hello_world.txt @@ -1,2 +1,3 @@ Hello world! Bye, bye! +See you soon! 

Таким образом, мы сократим id коммита, а также исключим авторство и дату коммита.

Подробнее с командой `git show` и с её параметрами можно ознакомиться перейдя по ссылке.

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

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

Это возможно за счет того, что git reflog хранит свою информацию на вашей машине отдельно от коммитов, поэтому при удалении чего-либо в истории, в сможете это найти в git reflog .

Вывод этой команды выглядит следующим образом:

957e113 (HEAD -> master) HEAD@: commit: fourth commit ekd53dk HEAD@: commit: third commt dslf445 HEAD@: commit: second commit h4k4o5j HEAD@: commit (intial): first commit 

Теперь давайте рассмотрим очень полезную команду `git reset`. Она позволяет откатить проект до определенной точки.

Эту команду можно использовать с тремя параметрами:

  • git reset —soft
  • git reset —mixed
  • git reset —hard

Рассмотрим их по порядку. Для этого сначала давайте вспомним, что такое index. Как я упоминал ранее, index — это временный файл, который фиксирует структуру Git проекта в определенный момент времени. Это важная деталь сейчас, поскольку команда git reset в зависимости от параметра прокидывает нас в истории проекта с соответствующими состояниями индекса.

1. В случае с —soft , содержимое вашего индекса, а также рабочей директории, остается неизменным. Это значит, что если мы откатимся назад на пару коммитов, мы изменим ссылку указателя HEAD на указанный коммит и все изменения, которые были до этого внесены, окажутся в индексе.

2. При использовании параметра —mixed , мы опять-таки изменим ссылку указателя HEAD, но все предыдущие изменения в индекс не попадут, а будут отслеживаться как не занесенные в индекс. Это дает возможность внести в индекс только те изменения, которые нам необходимы, что довольно удобно!

3. Если использовать команду git reset с параметром —hard , мы снова изменим ссылку указателя HEAD, но все предыдущие изменения не попадут ни в индекс, ни в зону отслеживаемых файлов. Это значит, что мы полностью сотрем все изменения, которые вносили ранее. Это также удобно, если вы знаете, что вам больше не пригодится ваша предыдущая работа над проектом.

Давайте вернемся к нашему репозиторию и рассмотрим следующий пример:

git log —oneline

957e113 (HEAD -> master) fourth commit ekd53dk third commit dslf445 second commit h4k4o5j first commit

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

git reset —soft 349de9d

Далее, проверим индекс:

On branch master Changes to be committed: (use "git restore --staged . " to unstage) modified: hello_world.txt

И снова git log —oneline :

dslf445 (HEAD -> master) second commit h4k4o5j first commit

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

Теперь повторим наши действия, но уже с параметром —mixed :

git reset —mixed 349de9d

Проверим git status:

On branch master Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) modified: hello_world.txt

А также git log —oneline :

dslf445 (HEAD -> master) second commit h4k4o5j first commit

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

И в заключении повторим ту же последовательность действий с параметром —hard .

git reset —hard 349de9d

Снова проверяем git status :

On branch master nothing to commit, working tree clean

И git log —oneline :

dslf445 (HEAD -> master) second commit h4k4o5j first commit

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

И если посмотреть сейчас содержимое файла, то мы увидим единственную строку “Hello, world!”, которую мы с вами добавляли в файл во втором коммите.

Ветвление в Git

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

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

Давайте попробуем с этим поработать на нашем примере. У нас имеется следующая последовательность коммитов.

957e113 (HEAD -> master) fourth commit ekd53dk third commit dslf445 second commit h4k4o5j first commit

Git по умолчанию во время инициализации создает ветку master и уже ведет свою работу в ней. Мы можем в этом убедиться введя команду:

* master

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

Делается это при помощи команды git branch . Давайте создадим ветку “dev”:

Теперь введя команду git branch мы увидим следующее:

 dev * master

Звёздочкой Git указывает на текущую ветку, в которой мы работаем.

Для того чтобы переключиться на другую ветку используют команду git checkout . Давайте переключимся на ветку “dev”.

git checkout dev

Switched to branch 'dev'

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

Взглянем на git log —oneline :

dece9c9 (HEAD -> dev) fifth commit 957e113 (master) fourth commit ekd53dk third commit dslf445 second commit h4k4o5j first commit

Как и следовало ожидать, в нашей истории появился еще один — пятый коммит.

Теперь перейдем на ветку master

git checkout master

И просмотрим git log —oneline , и убедимся в том что все осталось без изменений.

957e113 (HEAD -> master) fourth commit ekd53dk third commit dslf445 second commit h4k4o5j first commit

Помимо разделения истории в Git мы также можем соединять воедино два потока разработки. Это значит, что нашу проделанную работу в новой ветке мы можем слить обратно в master. Такой процесс слияния можно выполнить при помощи команды git merge . То есть, если мы хотим слить изменения из ветки “dev” в ветку “master”, нам необходимо перейти на ветку “master” и в ней выполнить:

Updating 957e113..dece9c9 Fast-forward hello_world.txt | 1 + 1 file chaged, 1 insertion(+)

Теперь если мы проверим git log —oneline , то убедимся в том, что новый коммит из ветки “dev” переместился в ветку “master”.

dece9c9 (HEAD -> master, dev) fifth commit 957e113 fourth commit ekd53dk third commit dslf445 second commit h4k4o5j first commit

Теперь от ненужной ветки можно избавиться и удалить её с помощью команды git branch -d .

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

Примеры ведения истории проекта

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

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

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

1. Сообщение коммита:

Ниже представлен шаблон наших сообщений коммита:

Мы указываем дату совершения коммита и версию приложения для удобства поиска работы в истории.

Модификаторы формата коммита предоставляют информацию о том какой фронт работы был выполнен в этом коммите.

Мы используем следующие модификаторы:

  • Dev: — указывает на то, что в коммите велась разработка нового функционала.
  • Refactoring: — данный модификатор сообщает о рефакторинге проведенном в коде.
  • Fix: — в данном коммите фиксили баги.
  • Release: — данный коммит отправлен в ветку «release» и хранит состояние релизной версии приложения.

Также в конце сообщения мы оставляем короткое описание — над чем мы работали в этом коммите.

2. Стратегия ветвления:

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

В нашем случае, мы выделяем две основные ветки master и «release». Master используется для подготовки к выкладке новых версий приложения. Код попавший в «master» проходит автоматические тесты, после которых выполняется сборка проекта, которую необходимо вручную протестировать перед дальнейшими действиями. Далее если замечаний к работе нет, мы сливаем ветку «master» в ветку «release». Там снова запускаются автоматические тесты, и собираются сборки к выкладке в маркеты.

Для ведения разработки мы создаем feature векти. Это означает, что каждая ветка отвечает за разработку какой-нибудь функциональности. Например, если мы хотим внедрить в приложение хранение данных в облаке, то программист создаст ветку «feature-cloud» и будет вести работу в ней.

Заключение

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

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

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

А также на книги, которыми я пользовался и интернет ресурсы:

1. “Version control with Git” — Jon Loeliger;

2. “Pro Git” — Scott Chacon, Ben Straub.

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

Спасибо за ваше внимание!

Команда git-log: опции, ключи и примеры использования

Общие команды – Общие команды, присущие различным операционным системам.

Переведено в рамках проекта tldr-ru. Licensed under the CC-BY (original work).

git log

  • Показать последовательность коммитов в обратном хронологическом порядке, начиная с текущего:
  • Показать историю конкретного файла или каталога, включая разницу:
  • Показать только первую строку каждого сообщения коммита:

git log —oneline

  • Показать все коммиты, теги и ветки репозитория в формате диаграммы:

git log —oneline —decorate —all —graph

  • Показать только коммиты, содержащие указанную строку (без учёта регистра):

Изображение Выучи 10 хороших привычек для работы в UNIX от IBM

Примеры кода, демонстрирующие общие подходы в программировании или же решающие небольшие прикладные задачи. Языки программирования и библиотеки, позволяющие эффективно решать задачи разработки. Объектно-ориентированное программирование, функциональное программирование и прочие подходы и …

Фото Код

Трюки Bash

Полезные заметки по работе с командной строкой: bash и прочие *sh. Однострочники, скрипты, позволяющие решать большие и малые задачи администрирования и настройки Юникс систем. Zsh для современного MacOS, Bash для …

Фото Трюки Bash

Заметки о настройке различных IT-штуковин. Настройка, допиливание, полировка. Конфигурируем приложения и тюнингуем сервера. Полезные параметры и ключи запуска программ. Увеличиваем скорость, уменьшаем отклик, ускоряем работу и улучшаем результаты работы. Объясняем …

Фото Настройки

Терминал/Консоль

Команды и инструкции терминала (консоли) Linux, MacOS, Windows и прочих операционных систем. Трюки и особенности командных оболочек, скрипты для администрирования Unix. Программирование и скриптование Windows и Linux, тонкая настройка Macos. …

Фото Терминал/Консоль

Также может быть вам интересно:

  • Как получить дерево директорий на Bash одним однострочником
  • Python: Функции
  • Python: Встроенные типы данных (list, set, dict, etc)
  • Python: типы данных, переменные, логическое ветвление и циклы
  • Как сделать свою middleware в Django (с примерами)

Свежее на «Цифре»
MessageId или как дебажить систему с минимумом проблем
Программы, 49 дней назад
Проверочный список для выпуска промышленных приложений с иллюстрациями
Работа и управление, 90 дней назад
В Google Pixel и Windows Snipping Tool есть возможность восстановления обрезанных изображений
Новости, 23.03.2023
Два подарка «под ёлочку» от Heroes of Might and Magic
Новости, 25.12.2022
Вышел Pulsar – редактор кода на основе Atom
Новости, 25.12.2022
Ленивый backup PostgreSQL
Программы, 17.12.2022
Google анонсировала OSV-Scanner: сканер уязвимостей в программных проектах
Новости, 16.12.2022

Фото Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

На днях группа бывших разработчиков Gitea решили создать на базе хостинга кода Gitea свою версию проекта – «Forgejo». Причиной тому …

Фото Пользователи и их создание в Django - своя регистрация на сайте

Пользователи и их создание в Django — своя регистрация на сайте

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

Фото Новый синтаксис старой команды with в Python 3.10

Новый синтаксис старой команды with в Python 3.10

Как же долго моё чувство прекрасного страдало… Но в Python 3.10 появился новый парсер синтаксических конструкций Python!

Фото Добавляем постраничную пагинацию на Django сайт

Добавляем постраничную пагинацию на Django сайт

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

Фото Новый оператор match-case в Python

Новый оператор match-case в Python

В новой версии Python (3.10) появится новый оператор. Новый оператор сопоставления по шаблону (match-case).

Фото Нет слов, одни. однострочники

Нет слов, одни. однострочники

На днях вышел пост со списком полезных однострочников для JavaScript программистов. Памятуя Perl-овую молодость, заглянул туда.

Фото Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если …

Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать …

Фото Разграничение прав доступа на Django сайте

Разграничение прав доступа на Django сайте

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *