Git список коммитов: Просмотр истории коммитов в Git

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

19 июня 2013
  
 
git
VCS

Изучение истории коммитов — важная составляющая работы с репозиторием. Увы, ввиду ветвления с этой историей не всегда просто разобраться. Обычно я для этой цели пользуюсь различными визуальными оболочками, но не всегда есть такая возможность. Временами приходится пользоваться средствами консоли, а именно командой
git log. Основы работы с этой командой можно почитать в чудесной книге
ProGit
.
git log
имеет множество различных полезных параметров. Рассмотрим несколько примеров их использования.

Древовидный вид

git log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all

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

git log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

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

git log --graph --oneline --all

Выводим полный граф коммитов, отводя по одной строке на коммит.

git log --graph --date-order --pretty=format:"<%h> %ad [%an] %Cgreen%d%Creset %s" --all --date=short

Выводим полный граф коммитов c сортировкой по дате, отображаемой в краткой форме. Используемый формат: сокращённый хеш, дата, автор, зелёные ссылки на коммит, сообщение.

Линейный вид

Вывод списка коммитов с параметрами по умолчанию.

Выводим список коммитов и показываем diff для каждого.

Выводим список коммитов и показываем статистику по каждому.

Pro Git: Основы Git — Просмотр истории коммитов

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

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

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

В результате выполнения git log в данном проекте, видим это:

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

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

Один из наиболее полезных параметров — это -p, который показывает дельту (разницу/diff), привнесенную каждым коммитом. Вы также можете использовать -2, что ограничит вывод до 2-х последних записей:

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

В некоторых ситуациях гораздо удобней просматривать внесённые изменения на уровне слов, а не на уровне строк. Чтобы получить дельту по словам вместо обычной дельты по строкам, нужно дописать после команды git log -p опцию —word-diff. Дельты на уровне слов практически бесполезны при работе над программным кодом, но они буду очень кстати при работе над длинным текстом, таким как книга или диссертация. Я изменил  Рассмотрим пример:

Как видите, в этом выводе нет ни добавленных ни удалённых строк, как для обычного diff’а. Вместо этого изменения показаны внутри строки. Добавленное слово заключено в {+ +}, а удалённое в [- -].

С командой git log вы также можете использовать группы суммирующих параметров. Например, если вы хотите получить некоторую краткую статистику по каждому коммиту, вы можете использовать параметр —stat:

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

ругой действительно полезный параметр — это —pretty. Он позволяет изменить формат вывода лога. Для вас доступны несколько предустановленных вариантов. Параметр oneline выводит каждый коммит в одну строку, что удобно если вы просматриваете большое количество коммитов. В дополнение к этому, параметры short, full, и fuller, практически не меняя формат вывода, позволяют выводить меньше или больше деталей соответственно:

Наиболее интересный параметр — это format, который позволяет вам полностью создать собственный формат вывода лога. Это особенно полезно, когда вы создаёте отчёты для автоматического разбора (парсинга) — поскольку вы явно задаёте формат и уверены в том, что он не будет изменяться при обновлениях Git’а:

Параметр	Описание выводимых данных
%H	Хеш коммита
%h	Сокращённый хеш коммита
%T	Хеш дерева
%t	Сокращённый хеш дерева
%P	Хеши родительских коммитов
%p	Сокращённые хеши родительских коммитов
%an	Имя автора
%ae	Электронная почта автора
%ad	Дата автора (формат соответствует параметру --date=)
%ar	Дата автора, относительная (пр. «2 мес. назад»)
%cn	Имя коммитера
%ce	Электронная почта коммитера
%cd	Дата коммитера
%cr	Дата коммитера, относительная
%s	Комментарий

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

Параметры oneline и format также полезны с другим параметром команды log — —graph. Этот параметр добавляет миленький ASCII-граф, показывающий историю ветвлений и слияний.

Мы рассмотрели только самые простые параметры форматирования вывода для git log — их гораздо больше. Таблица ниже содержит как уже рассмотренные нами параметры, так и другие полезные параметры вместе с описанием того, как они влияют на вывод команды log.

Параметр	Описание
-p	Для каждого коммита показывать дельту внесённых им изменений.
--word-diff	Показывать изменения на уровне слов.
--stat	Для каждого коммита дополнительно выводить статистику по изменённым файлам.
--shortstat	Показывать только строку changed/insertions/deletions от вывода с опцией --stat.
--name-only	Показывать список изменённых файлов после информации о коммите.
--name-status	Выводить список изменённых файлов вместе с информацией о добавлении/изменении/удалении.
--abbrev-commit	Выводить только первые несколько символов контрольной суммы SHA-1 вместо всех 40.
--relative-date	Выводить дату в относительном формате (например, «2 weeks ago») вместо полной даты.
--graph	Показывать ASCII-граф истории ветвлений и слияний рядом с выводом лога.
--pretty	Отображать коммиты в альтернативном формате. Возможные параметры: oneline, short, full, fuller и format (где вы можете указать свой собственный формат).

Ограничение вывода команды log

Кроме опций для форматирования вывода, git log имеет ряд полезных ограничительных параметров, то есть параметров, которые дают возможность отобразить часть коммитов. Вы уже видели один из таких параметров — параметр -2, который отображает только два последних коммита. На самом деле, вы можете задать -<n>, где n это количество отображаемых коммитов. На практике вам вряд ли придётся часто этим пользоваться потому, что по умолчанию Git через канал (pipe) отправляет весь вывод на pager, так что вы всегда будете видеть только одну страницу.

А вот параметры, ограничивающие по времени, такие как —since и —until, весьма полезны. Например, следующая команда выдаёт список коммитов, сделанных за последние две недели:

$ git log —since=2.weeks

Такая команда может работать с множеством форматов — вы можете указать точную дату (“2008-01-15”) или относительную дату, такую как “2 years 1 day 3 minutes ago”.

Вы также можете отфильтровать список коммитов по какому-либо критерию поиска. Опция —author позволяет фильтровать по автору, опция —grep позволяет искать по ключевым словам в сообщении. (Заметим, что, если вы укажете и опцию author, и опцию grep, то будут найдены все коммиты, которые удовлетворяют первому ИЛИ второму критерию. Чтобы найти коммиты, которые удовлетворяют первому И второму критерию, следует добавить опцию —all-match.)

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

Последняя действительно полезная опция-фильтр для git log — это путь. Указав имя каталога или файла, вы ограничите вывод log теми коммитами, которые вносят изменения в указанные файлы. Эта опция всегда указывается последней и обычно предваряется двумя минусами для каталога (—), чтобы отделить пути от остальных опций. Для файла в корневом каталоге Git можно просто указать его имя.

Список часто употребляемых опций.

Опция	Описание
-(n)	Показать последние n коммитов
--since, --after	Ограничить коммиты теми, которые сделаны после указанной даты.
--until, --before	Ограничить коммиты теми, которые сделаны до указанной даты.
--author	Показать только те коммиты, автор которых соответствует указанной строке.
--committer	Показать только те коммиты, коммитер которых соответствует указанной строке.
--grep	Показать только те коммиты, в комментарии содержат искомую строку.
-S	Показать только те коммиты, в которых менялась искомая строка.

Использование графического интерфейса для визуализации истории

Если у вас есть желание использовать какой-нибудь графический инструмент для визуализации истории коммитов, можно попробовать распространяемую вместе с Git’ом программу gitk, написанную на Tcl/Tk. В сущности gitk — это наглядный вариант git log, к тому же он принимает почти те же фильтрующие опции, что и git log.

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

Git для начинающих. Часть 6. Просмотр информации по коммитам

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

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

1. Внесение изменений в рабочую директорию.
2. Отправка изменений в stage.
3. Формирование и отправка коммита на базе того, что лежит в stage, в репозиторий.

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

Для просмотра информации по сделанным вами (или вашими коллегами) коммитам используется команда git log.

> git log
commit a98cce47b59256d00a853c421af4f7b9f0dc0a29
Author: Writer <writer@somecompany. com>
Date:   Mon Mar 5 23:10:51 2018 +0500

    [create repository]

Как видно из полученной информации, в репозиторий был отправлен один коммит с сообщением “[create repository]”, этот коммит сделал пользователь с именем Writer, его email: [email protected], уникальный идентификатор коммита a98cce47b59256d00a853c421af4f7b9f0dc0a29, и дата и время отправки коммита: 5 марта 2018 в 23:10:51.

Внесем еще несколько изменений в наш репозитории. Добавим текст в файл README.md.

> echo "Project 51" > README.md

Зафиксируем эти изменения в репозитории.

> git add .
> git commit -m "[add]: caption into README file"

Создадим файл main.c и добавим его в репозиторий.

> touch main.c
> git add .
> git commit -m "[create]: main file of program"

Таким образом в нашем репозитории уже должно быть три коммита, проверим это.

> git log
commit 2b826bb4929fb1c8166ef05b540ce2cc68f3ebb2
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:17:08 2018 +0500

    [create]: main file of program

commit bc067c88c427dbedbb02817f9ae25241dcae4d07
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:15:12 2018 +0500

    [add]: caption into README file

commit a98cce47b59256d00a853c421af4f7b9f0dc0a29
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:10:51 2018 +0500

    [create repository]

Коммиты располагаются от новых к старым. Сделаем ещё несколько изменений.

> touch main.h
> git add .
> git commit -m "[create]: header for main"
> touch .gitignore
> git add .
> git commit -m "[create]: git ignore file"
> echo "*.tmp" > .gitignore
> git add .
> git commit -m "[add] ignore .tmp files">

Снова получим список всех коммитов.

> git log
commit cf3d9d8f7b283267a085986e85cc8f152cca420d
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:21:59 2018 +0500

    [add] ignore .tmp files

commit a7b88eed6110b6ebb1fc4d96f4399e4cbb8339e7
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:21:11 2018 +0500

    [create]: git ignore file

commit c185b80ca916af7d6f068450f6cafb073d955c40
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:20:26 2018 +0500

    [create]: header for main

commit 2b826bb4929fb1c8166ef05b540ce2cc68f3ebb2
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:17:08 2018 +0500

    [create]: main file of program

commit bc067c88c427dbedbb02817f9ae25241dcae4d07
Author: Writer <[email protected]>
Date:   Mon Mar 5 23:15:12 2018 +0500

    [add]: caption into README file

commit a98cce47b59256d00a853c421af4f7b9f0dc0a29
Author: Writer <writer@somecompany. com>
Date:   Mon Mar 5 23:10:51 2018 +0500

    [create repository]

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

> git log --oneline
cf3d9d8 [add] ignore .tmp files
a7b88ee [create]: git ignore file
c185b80 [create]: header for main
2b826bb [create]: main file of program
bc067c8 [add]: caption into README file
a98cce4 [create repository]

В таком виде работать с коммитами уже намного удобнее. Если вы хотите просмотреть n последних коммитов, то укажите количество коммитов после ключа -n. Выведем три последних коммита.

> git log -n 3 --oneline
cf3d9d8 [add] ignore .tmp files
a7b88ee [create]: git ignore file
c185b80 [create]: header for main

Для вывода списка коммитов, начиная с какой-то временной метки, используйте ключ –since=”<date> <time>”.  Например, получим все коммиты, сделанные после 5-го марта 2018 года 23:21.

> git log --since="2018-03-05 23:21:00" --oneline
cf3d9d8 [add] ignore .tmp files
a7b88ee [create]: git ignore file

Для вывода списка коммитов до какой-то даты используется ключ –until. Получим список коммитов, сделанных до 5-го марта 2018 года 23:21.

> git log --until="2018-03-05 23:21:00" --oneline
c185b80 [create]: header for main
2b826bb [create]: main file of program
bc067c8 [add]: caption into README file
a98cce4 [create repository]

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

> git log --author="Writer" --oneline
cf3d9d8 [add] ignore .tmp files
a7b88ee [create]: git ignore file
c185b80 [create]: header for main
2b826bb [create]: main file of program
bc067c8 [add]: caption into README file
a98cce4 [create repository]

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

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

> git log --grep="create" --oneline
a7b88ee [create]: git ignore file
c185b80 [create]: header for main
2b826bb [create]: main file of program
a98cce4 [create repository]

Теперь коммиты со словом add.

> git log --grep="add" --oneline
cf3d9d8 [add] ignore .tmp files
bc067c8 [add]: caption into README file

Для более продуктивного использования данной команды рекомендуем ознакомиться с возможностями утилиты grep. На этом мы закончим обзор команды git log.

Отличный курс по git  делают ребята из GeekBrains, найдите в разделе “Курсы” курс “Git. Быстрый старт”, он бесплатный!

<<< Часть 5. Создание репозитория и первый коммит Часть 7. Поговорим о HEAD и tree-ish>>>

Просмотр истории коммитов | Pro Git

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

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


git clone git://github.com/schacon/simplegit-progit.git


В результате выполнения git log в данном проекте, вы должны получить что-то вроде этого:


$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700

changed the version number

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon
Date: Sat Mar 15 10:31:28 2008 -0700

first commit

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

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

Один из наиболее полезных параметров — это -p, который показывает дельту(разницу/diff) привнесенную каждым коммитом. Вы также можете использовать -2, что ограничит вывод до 2-х последних записей:


$ git log -p -2
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700

changed the version number

diff —git a/Rakefile b/Rakefile
index a874b73..8f94139 100644
— a/Rakefile
+++ b/Rakefile
@@ -5,7 +5,7 @@ require ‘rake/gempackagetask’
spec = Gem::Specification. new do |s|
— s.version = «0.1.0»
+ s.version = «0.1.1»
s.author = «Scott Chacon»

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code

diff —git a/lib/simplegit.rb b/lib/simplegit.rb
index a0a60ae..47c6340 100644
— a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -18,8 +18,3 @@ class SimpleGit
end

end
—
-if $0 == __FILE__
— git = SimpleGit.new
— puts git.show
-end
\ No newline at end of file

Этот параметр показывает ту же самую информацию плюс внесённые изменения, отображаемые непосредственно после каждого коммита. Это очень удобно для инспекций кода или для того, чтобы быстро посмотреть что происходило в результате последовательности коммитов добавленных коллегой. С командой git log вы также можете использовать группы суммирующих параметров. Например, если вы хотите получить некоторую краткую статистику по каждому коммиту, вы можете использовать параметр --stat:


$ git log --stat
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon
Date: Mon Mar 17 21:52:11 2008 -0700

changed the version number

Rakefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon
Date: Sat Mar 15 16:40:33 2008 -0700

removed unnecessary test code

lib/simplegit. rb | 5 ——
1 files changed, 0 insertions(+), 5 deletions(-)

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon
Date: Sat Mar 15 10:31:28 2008 -0700

first commit

README | 6 ++++++
Rakefile | 23 +++++++++++++++++++++++
lib/simplegit.rb | 25 +++++++++++++++++++++++++
3 files changed, 54 insertions(+), 0 deletions(-)

Как видно из лога, параметр --stat выводит под каждым коммитом список измененных файлов, количество измененных файлов, а также количество добавленных и удаленных строк в этих файлах. Он также выводит сводную информацию в конце. Другой действительно полезный параметр — это --pretty. Он позволяет изменить формат вывода лога. Для вас доступны несколько предустановленных вариантов. Параметр oneline выводит каждый коммит в одну строку, что удобно если вы просматриваете большое количество коммитов. В дополнение к этому, параметры short, full, и fuller практически не меняя формат вывода позволяют выводить меньше или больше деталей соответственно:


$ git log --pretty=oneline
ca82a6dff817ec66f44342007202690a93763949 changed the version number
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
a11bef06a3f659402fe7563abf99ad00de2209e6 first commit


Наиболее интересный параметр — это format, который позволяет вам полностью создать собственный формат вывода лога. Это особенно полезно, когда вы создаете отчеты для автоматического разбора(парсинга) — поскольку вы явно задаете формат и уверены в том, что он не будет изменяться при обновлениях Git:


$ git log --pretty=format:"%h - %an, %ar : %s"
ca82a6d - Scott Chacon, 11 months ago : changed the version number
085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
a11bef0 - Scott Chacon, 11 months ago : first commit


Таблица 2-1 содержит список наиболее полезных параметров формата.


Параметр Описание выводимых данных
`%H` Хеш коммита
`%h` Сокращенный хеш коммита
`%T` Хеш дерева
`%t` Сокращенный хеш дерева
`%P` Хеши родительских коммитов
`%p` Сокращенные хеши родительских коммитов
`%an` Имя автора
`%ae` Электронная почта автора
`%ad` Дата автора (формат соответствует параметру --date= )
`%ar` Дата автора, относительная (пр. "2 мес. назад")
`%cn` Имя коммитера
`%ce` Электронная почта коммитера
`%cd` Дата коммитера
`%cr` Дата коммитера, относительная
`%s` Комментарий


Вас может заинтересовать в чём же разница между автором и коммитером. Автор — это человек, изначально сделавший работу, тогда как коммитер — это человек, который последним применил эту работу. Так что если вы послали патч(заплатку) в проект и один из основных разработчиков применил этот патч, вы оба не будете забыты — вы как автор, а разработчик как коммитер. Мы чуть подробнее рассмотрим это различие в Главе Распределённый Git.

Параметры oneline и format также полезны с другим параметром команды log — --graph. Этот параметр добавляет миленький ASCII граф показывающий историю ветвлений и слияний. Один из таких можно увидеть для нашей копии репозитория проекта Grit:


$ 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
* 11d191e Merge branch 'defunkt' into local


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


Параметр Описание
`-p` Выводит патч (заплатку/diff) внесенный каждым коммитом.
`--stat` Выводит статистику по файлам измененным в каждом коммите.
`--shortstat` Отображает только строку с changed/insertions/deletions от вывода команды `--stat`.
`--name-only` Выводит список измененных файлов после каждого коммита.
`--name-status` Выводит список файлов вместе с информацией о добавлении/изменении/удалении.
`--abbrev-commit` Выводит только первые несколько символов контрольной суммы SHA-1 вместо всех 40.
`--relative-date` Выводит дату в относительном формате (например, “2 недели назад”) вместо использования полного формата даты.
`--graph` Выводит ASCII граф истории ветвлений и слияний рядом с выводом лога.
`--pretty` Выводит коммиты в альтернативном формате. Параметры включают oneline, short, full, fuller, и format (где вы можете указать свой собственный формат).


Ограничение вывода команды log

Кроме опций для форматирования вывода, git log имеет ряд полезных ограничительных параметров, то есть параметров, которые дают возможность отобразить часть коммитов. Вы уже видели один из таких параметров — параметр -2, который отображает только два последних коммита. На самом деле, вы можете задать -, где n это количество отображаемых коммитов. На практике вам вряд ли придётся часто этим пользоваться потому, что по умолчанию Git через канал (pipe) отправляет весь вывод на pager, так что вы всегда будете видеть только одну страницу.

А вот, параметры ограничивающие по времени такие как --since и --until весьма полезны. Например, следующая команда выдаёт список коммитов сделаных за последние две недели:


$ git log --since=2.weeks


Такая команда может работать с множеством форматов — вы можете указать точную дату (“2008-01-15”) или относительную дату такую как “2 years 1 day 3 minutes ago”.

Вы также можете отфильтровать список коммитов так, чтобы получить те, которые удовлетворяют какому-то критерию поиска. Опция --author позволяет фильтровать по автору, опция --grep позволяет искать по ключевым словам в сообщении. (Заметим, что, если вы укажете и опцию author, и опцию grep, то будут найдены все коммиты, которые удовлетворяют первому ИЛИ второму критерию. Чтобы найти коммиты, которые удовлетворяют первому И второму критерию, следует добавить опцию --all-match.)

Последняя действительно полезная опция-фильтр для git log это путь. Указав имя директории или файла, вы ограничите вывод log теми коммитами, которые вносят изменения в указанные файлы. Эта опция всегда указывается последней и обычно предваряется двумя минусами (--), чтобы отделить пути от остальных опций.

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


Опция Описание
`-(n)` Показать последние n коммитов
`--since`, `--after` Ограничить коммиты теми, которые сделаны после указанной даты.
`--until`, `--before` Ограничить коммиты теми, которые сделаны до указанной даты.
В верхней части окна располагается история коммитов вместе с подробным графом наследников. Просмотрщик дельт в нижней половине окна отображает изменения сделанные выбранным коммитом. Указать коммит можно с помощью щелчка мышью.`--author` Показать только те коммиты, автор которых соответствует указанной строке.
`--committer` Показать только те коммиты, коммитер которых соответствует указанной строке.


Например, если вы хотите посмотреть из истории Git такие коммиты, которые вносят изменения в тестовые файлы, были сделаны Junio Hamano, не являются слияниями и были сделаны в октябре 2008го, вы можете выполнить что-то вроде такого:


$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
--before="2008-11-01" --no-merges -- t/
5610e3b - Fix testcase failure when extended attribute
acd3b9e - Enhance hold_lock_file_for_{update,append}()
f563754 - demonstrate breakage of detached checkout wi
d1a43f2 - reset --hard/read-tree --reset -u: remove un
51a94af - Fix "checkout --track -b newbranch" on detac
b0ad11e - pull: allow "git pull origin $something:$cur


Из примерно 20 000 коммитов в истории Git, данная команда выбрала всего 6 коммитов соответствующих заданным критериям.

Использование графического интерфейса для визуализации истории

Если у вас есть желание использовать какой-нибудь графический инструмент для визуализации истории коммитов, можно попробовать распространяемую вместе с Git программу gitk, написанную на Tcl/Tk. В сущности gitk — это наглядный вариант git log, к тому же он принимает почти те же фильтрующие опции, что и git log. Если набрать в командной строке gitk находясь в проекте, вы увидете что-то наподобие Рис. 2-2.

Рисунок 2-2. Визуализация истории с помощью gitk

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

Pro Git

Cистема контроля версий Git: расширенная шпаргалка

Git — это популярная система контроля версий. \*\| master’ | xargs -n 1 git branch -d

git branch -vv

git branch -u origin/mybranch

git branch -d <local_branchname>

git push origin --delete <remote_branchname>

Альтернатива:

git push origin :<remote_branchname>

git tag -d <tag-name>

git push origin :refs/tags/<tag-name>

git checkout -- <file_name>

git revert <commit-ish>

git reset <commit-ish>

git commit -v --amend

git cherry -v master

git commit --amend --author='Author Name <[email protected]>'

git commit --amend --reset-author --no-edit

git remote set-url origin <URL>

git remote

Альтернатива:

git remote show

git branch -a

git branch -r

git add -p

curl http://git.io/vfhol > ~/.git-completion.bash && echo '[ -f ~/. git-completion.bash ] && . ~/.git-completion.bash' >> ~/.bashrc

git log --no-merges --raw --since='2 weeks ago'

Альтернатива:

git whatchanged --since='2 weeks ago'

git log --no-merges --stat --reverse master..

git checkout <branch-name> && git cherry-pick <commit-ish>

git branch -a --contains <commit-ish>

Альтернатива:

git branch --contains <commit-ish>

git config --global alias.<handle> <command> 
git config --global alias.st status

git stash

Альтернатива:

git stash save

git stash -k

Альтернатива:

git stash --keep-index

git stash save --keep-index

git stash -u

Альтернатива:

git stash save -u

git stash save --include-untracked

git stash save <message>

git stash -a

Альтернатива:

git stash --all

git stash save --all

git stash list

git stash apply <stash@{n}>

git checkout <stash@{n}> -- <file_path>

Альтернатива:

git checkout stash@{0} -- <file_path>

git ls-files -t

git ls-files --others

git ls-files --others -i --exclude-standard

git worktree add -b <branch-name> <path> <start-point>

git rm --cached <file_path>

Альтернатива:

git rm --cached -r <directory_path>

git clean -n

git clean -f

git clean -f -d

git submodule foreach git pull

Альтернатива:

git submodule update --init --recursive

git submodule update --remote

git cherry -v master

Альтернатива:

git cherry -v master <branch-to-be-merged>

git branch -m <new-branch-name>

Альтернатива:

git branch -m [<old-branch-name>] <new-branch-name>

git archive master --format=zip --output=master. zip

git add --all && git commit --amend --no-edit

git fetch -p

Альтернатива:

git remote prune origin

git log --pretty=oneline --graph --decorate --all

Альтернатива:

gitk --all

git subtree push --prefix subfolder_name origin gh-pages

git subtree add --prefix=<directory_name>/<project_name> --squash [email protected]:<username>/<project_name>.git master

git subtree pull --prefix=<directory_name>/<project_name> --squash [email protected]:<username>/<project_name>.git master

git bundle create <file> <branch-name>

git clone repo.bundle <repo-dir> -b <branch-name>

git rev-parse --abbrev-ref HEAD

git update-index --assume-unchanged Changelog; git commit -a; git update-index --no-assume-unchanged Changelog

git fetch origin pull/<id>/head:<branch-name>

Альтернатива:

git pull origin pull/<id>/head:<branch-name>

git describe --tags --abbrev=0

git diff --word-diff

git update-index --assume-unchanged <file_name>

git update-index --no-assume-unchanged <file_name>

git clean -X -f

git checkout <deleting_commit>^ -- <file_path>

git checkout <commit-ish> -- <file_path>

git config --list

git config --global core. editor '$EDITOR'

git config --global help.autocorrect 1

git name-rev --name-only <SHA-1>

git commit --fixup <SHA-1>

git commit --only <file_path>

git check-ignore *

git status --ignored

git log -<n>

Альтернатива:

git log -n <n>

git diff --name-only | uniq | xargs $EDITOR

git instaweb [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]

git log --show-signature

git config --global --unset <entry-name>

git checkout --orphan <branch_name>

git show <branch_name>:<file_name>

git rebase --interactive HEAD~2

git checkout master && git branch --no-merged

git bisect start                    
git bisect bad                      
git bisect good v2.6.13-rc2         
git bisect bad                    
git bisect good                     
git bisect reset

git log --follow -p -- <file_path>

git clone -b <branch-name> --single-branch https://github. com/user/repo.git

git checkout -b <branch-name>

Альтернатива:

git branch <branch-name> && git checkout <branch-name>

git config --global color.ui false

git config --global <specific command e.g branch, diff> <true, false or always>

git clone https://github.com/user/repo.git --depth 1

git log --all --grep='<given-text>'

git log master..<branch-name> --oneline | tail -1

git shortlog

git rev-list --count <branch-name>

git config --global alias.undo '!f() { git reset --hard $(git rev-parse --abbrev-ref HEAD)@{${1-1}}; }; f'

git notes add -m 'Note on the previous commit....'

git log --show-notes='*'

git --git-dir=<source-dir>/.git format-patch -k -1 --stdout <SHA1> | git am -3 -k

git log --branches --not --remotes

Альтернатива:

git log @{u}. alias\.//g'

Альтернатива:

git config -l | grep alias | cut -d '.' -f 2

git push -u origin <branch_name>

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

Перевод статьи «Git Concepts I Wish I Knew Years Ago».

Самая используемая разработчиками технология это вовсе не JavaScript.

Это не Python и не HTML.

Эту технологию даже практически не упоминают на собеседованиях или в объявлениях о вакансиях.

Я говорю о Git и системах контроля версий в целом.

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

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

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

Команды Git

Логирование

Что я только что сделал?

git log
git log --oneline # more succinct output
git log --graph # with a visual graph of branches

Просмотреть вашу «undo»-историю

git reflog

Иногда git log не справляется, особенно это касается команд, которые не показываются в истории коммитов. В таких случаях вам поможет reflog.

Команда reflog это ваша страховочная сетка после запуска «страшных» команд, таких как git rebase. С ее помощью вы увидите не только сделанные вами коммиты, но и все действия, которые привели вас к той точке, на которой вы находитесь. Узнать больше об этой команде можно из статьи Atlassian.

Посмотреть текущее состояние и сведения о возможных конфликтах слияния

git status

Хотя git status это одна из базовых команд, которые все мы изучаем в числе первых, она очень важна. Эта команда поможет вам сориентироваться в сложных случаях rebase или merge.

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

git diff --staged # для изменений в стейджинге
git diff # для изменений не в стейджинге

Навигация

Хочу посмотреть, что я делал раньше

git reset <commit-sha>

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

Вернуться к предыдущей ветке

git checkout -

Изменения

Я закопался по уши, давайте-ка начнем сначала

git reset --hard HEAD

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

Я хочу вернуть файл в первоначальное состояние

git checkout -- <bad-filename>

Я хочу отменить последний коммит и переписать историю

git reset --hard HEAD~1

Я хочу вернуться на n коммитов назад

git reset --hard HEAD~n # n это последние n коммитов
git reset --hard <commit-sha> # или вернуться к конкретному коммиту

Между soft, mixed и hard reset есть важные отличия. Если брать в целом,

1. --soft: убирает изменения из коммита, но сохраняет их в стейджинге.
2. --mixed (по умолчанию): изменения убираются из коммита и стейджинга, но остаются в рабочей директории.
3. --hard: изменения убираются из коммита, из стейджинга и из рабочей директории.

Я перезаписал историю и теперь хочу отправить эти изменения в удаленный репозиторий

git push -f

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

Я хочу добавить еще несколько изменений в последний коммит

git commit --amend

Хочу переписать несколько коммитов локально

git rebase -i <commit hash> # где commit hash это коммит перед всеми изменениями, которые вы хотите сделать

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

Я думаю, что rebase это одна из самых запутанных тем при изучении Git. Дальше мы еще к ней вернемся.

Этот rebase ни к чему хорошему не приведет, давайте его прервем

git rebase --abort

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

Я хочу внести коммит из другой ветки

# Запускается из ветки, в которую вы хотите внести коммит 
git cherry-pick <commit-sha>

Я хочу внести конкретный файл из другой ветки

git checkout <имя-ветки> <имя-файла>

Я больше не хочу отслеживать файл в системе контроля версий

git rm --cached <имя-файла>

Мне нужно переключиться между ветками, но мое текущее состояние нарушено

(Прим. ред. Techrocks: подробнее о git stash читайте здесь).

git stash # сохраняет ваши изменения сверху стека stash
git stash save "сообщение, касающееся изменений"
git stash -u # stash untracked files as well

Я хочу посмотреть, что у меня в stash

git stash list

Хочу вернуть что-то из stash

git stash pop # "выталкивает" самый недавний элемент, добавленный в стек stash
git stash apply stash@{stash_index} # применяет указанный элемент в stash (из git stash list)

Я хочу отменить коммит без переписывания истории

git revert HEAD # отменить последний коммит 
git revert <commit hash> # для конкретного коммита

Таким образом вы отмените изменения, создав новый коммит.(\+|\*|\s*(master|develop|dev)\s*$)» | command xargs -n 1 git branch -d’

Если вы используете Oh My Zosh, все это уже сделано за вас. Подробнее — в разделе про псевдонимы.

Отправляем в мусор старые ветки и лишние коммиты

git fetch --all --prune

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

Псевдонимы

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

Можно сделать еще лучше: установить инструмент вроде Oh My Zosh для Z shell (Zsh), и вы получите набор уже готовых псевдонимов для распространенных команд Git. Я вот слишком ленив, чтобы настраивать свою оболочку в точности по своему вкусу, так что предпочитаю пользоваться инструментами, которые делают это за меня. Кстати, Oh My Zosh и выглядит красиво.(\+|\*|\s*(master|develop|dev)\s*$)» | command xargs -n 1 git branch -d
gfa — git fetch —all —prune

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

alias

Или поискать по конкретному псевдониму:

alias grep <имя-псевдонима>

Другие приемы работы с Git

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

Многие файлы не предназначены для контроля версий. К ним относятся директории node_modules, .vscode или файлы других IDE и виртуальных сред Python. Для настройки игнорирования файлов следует использовать global gitignore.

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

Особые файлы

Вы можете пометить отдельные файлы как бинарные, чтобы Git игнорировал их и не продуцировал длинные diff-ы. Для этой цели в Git есть файл .gitattributes. В JavaScript-проекте вы можете захотеть внести в этот файл ваш yarn-lock.json или package-lock.json, чтобы Git не пытался сделать diff каждый раз, как вы вносите изменение.

# .gitattributes
package-lock.json binary

Рабочие процессы Git

Rebase vs Merge

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

Но даже если вы в основном используете merge, все равно можно пользоваться также и rebase. Наиболее распространенный случай эффективного применения rebase — когда вы работаете над каким-нибудь функционалом, а другой разработчик в это время добавил свою функцию в master. Вы, конечно, можете использовать git merge для внесения своих изменений, но теперь у вас есть один дополнительный коммит с изменениями, внесенными вашим товарищем по команде. Что вам на самом деле нужно сделать, это перенести свои коммиты на верх новой ветки master.

git rebase master

Таким образом у вас будет куда более чистая история коммитов.

Чтобы объяснить разницу, нужна отдельная статья, и я ее обязательно напишу, но пока можете почитать, что на этот счет говорится в документации Atlassian. (Прим. ред. Techrocks: на нашем сайте есть статья о git rebase и статья со сравнением revert, checkout, reset, merge и rebase).

Настройки удаленного репозитория

Я больше всего знаком с GitHub и GitLab, но эти настройки должны поддерживаться и другими менеджерами удаленных репозиториев.

1. Удаление веток при слиянии

Когда все изменения уже слиты, вам больше не нужны отдельные ветки, ведь история должна отражаться в вашей ветке master/dev. Такой подход существенно сокращает количество веток, которыми вам нужно управлять. Также благодаря этому команда git fetch --all --prune становится более эффективной в деле поддержки чистоты вашего локального репозитория.

2. Предотвращение отправки изменений напрямую в master

Без этого вы рискуете допустить весьма распространенную ошибку. Вы можете забыть, что находитесь в master, и выполнить git push, что потенциально способно сломать продакшен-сборку. А это не хорошо.

3. Необходимость получения как минимум одного одобрения перед слиянием

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

4. Необходимость прохождения CI-тестов для слияния

Изменения с дефектами не должны попадать в продакшен. Ревьюеры не всегда способны выловить 100% дефектов, так что стоит автоматизировать проверку.

Названия веток

Для облегчения навигации ваша команда может принять собственное соглашение об именах веток. Мне нравится начинать каждую ветку с первых буква имени и фамилии, за которыми следует косая черта и описание ветки (слова разделяются дефисами).

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

Например, я создаю новую ветку:

git checkout -b gabud/implement-important-feature

Неделю спустя, когда я забуду, как назвал ветку, я смогу начать вводить git checkout gabud (имя автора статьи — Gabriel Abud, — прим. перев.), нажать TAB — и моя Z shell (оболочка) покажет мне все мои локальные ветки. Таким образом я смогу выбрать нужную именно среди своих веток, не путая их с ветками коллег.

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

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

If this commit were applied, it would…

(Если этот коммит будет применен, он…)

Вот пример хорошего сообщения коммита в настоящем времени и повелительном наклонении:

git commit -m "Add a name field to the checkout form"

Теперь полная фраза будет читаться так: «If this commit were applied, it would add a name field to the checkout form» («Если этот коммит будет применен, он добавит поле имени в форму проверки»). Красиво и понятно.

Итоги

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

git_commit — документы Fastlane

документы скоростной полосы

• Дом

• • Начало работы
  • iOS

  • Настроить

  • Запуск тестов

  • Скриншоты

  • Бета-развертывание

  • Развертывание в App Store

  • Android

  • Настроить

  • Запуск тестов

  • Скриншоты

  • Бета-развертывание

  • Развертывание выпуска

  • Кросс-платформенный

  • React Native

  • Флаттер

  • NativeScript

• • Действия

  • Доступные действия

  • Создайте свое собственное действие

• Использование App Store Connect API

• FAQs

• • Коды

  • Начиная

  • Проект Xcode

  • Исправление проблем

  • Общие проблемы

• • Плагины

  • Доступные плагины

  • Используйте плагины

  • Создайте свой собственный плагин

  • Устранение неполадок плагинов

• • Лучшие практики

  • Управления источником

  • Непрерывная интеграция

  • Интеграции CI

  • Appcircle

  • Azure DevOps

  • Бамбук

  • Bitrise

  • CircleCI

  • GitLab CI

  • Дженкинс

  • NeverCode

  • Семафор

  • Трэвис

  • Ключи

• • Продвинутый

  • скоростная трасса

  • Fastfile

  • Файл приложения

  • Переулки

  • Действия

  • Другие

документы скоростной полосы

• Документы »
• Действия »
• git_commit

• Редактировать на GitHub

Зафиксируйте и отправьте изменения в репозиторий Git — PyCharm

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

Задайте свое имя пользователя Git

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

Зафиксировать изменения локально

В PyCharm вы можете зафиксировать изменения одним из следующих способов:

• В окне инструмента фиксации Alt + 0 : это способ по умолчанию для новых установок.Этот новый пользовательский интерфейс поддерживает совершенно другой подход к процедуре фиксации: в отличие от использования модального диалога фиксации, вы всегда находитесь в режиме фиксации и, следовательно, можете добавлять изменения в фиксацию, когда они будут готовы, сделать серию небольших фиксаций, и напишите сообщение фиксации итеративно.

• Через диалоговое окно «Принять изменения»: это способ по умолчанию для существующих пользователей.Вы можете переключиться на новый пользовательский интерфейс с помощью флажка Использовать немодальный интерфейс фиксации на странице Контроль версий | Страница фиксации настроек / предпочтений Ctrl + Alt + S .

Фиксация изменений из окна инструмента фиксации

1. Открыть вертикальное окно инструмента фиксации Alt + 0 , расположенное слева:

2. Когда ваши изменения готовы к фиксации, выберите соответствующие файлы или список изменений.

   Если вы нажмете Ctrl + K , будет выбран весь активный список изменений.

   Вы также можете выбрать файлы в узле «Неверсированные файлы» — PyCharm подготовит и зафиксирует эти файлы за один шаг.

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

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

   Вы можете настроить правила сообщений фиксации в диалоговом окне «Настройки / Предпочтения». Ctrl + Alt + S в разделе «Контроль версий | Диалог фиксации. Также есть быстрое исправление и действие «Переформатировать», которое переносит длинную строку или переформатирует сообщение.

4. Если вам необходимо выполнить проверки перед фиксацией, загрузить файлы на сервер после фиксации или зафиксировать с расширенными параметрами, щелкните в правом нижнем углу окна инструмента:

   Доступны следующие параметры:

   • Автор: если вы фиксируете изменения, сделанные другим человеком, вы можете указать автора этих изменений.

   • Исправить фиксацию: позволяет добавлять локальные изменения в последнюю фиксацию.

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

     Когда этот параметр включен, в конец сообщения о фиксации автоматически добавляется следующая строка: Подписано: <имя пользователя>

   • В области Перед фиксацией выберите действия, которые PyCharm должен выполнить перед фиксацией выбранного файлы в локальный репозиторий.

   • В области «После фиксации» вы можете выбрать конфигурацию доступа к серверу или группу серверов, которые будут использоваться для загрузки зафиксированных файлов на локальный или удаленный хост, смонтированный диск или каталог. См. Подробности в разделе «Развертывание».

5. Когда вы будете готовы, нажмите «Принять» или щелкните стрелку на кнопке «Принять», чтобы отобразить доступные параметры:

   • Принять и нажать ( Ctrl + Alt + K ): нажмите на изменения в удаленный репозиторий сразу после фиксации.Вы сможете просмотреть текущую фиксацию, а также все другие фиксации, прежде чем они будут отправлены на удаленный компьютер.

   • Создать исправление: создание исправления на основе изменений, которые вы собираетесь зафиксировать. В диалоговом окне Create Patch введите имя файла патча и укажите, нужен ли вам обратный патч.

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

Фиксация изменений в диалоговом окне «Фиксация»

1. Выберите файлы, которые вы хотите зафиксировать, или весь список изменений в представлении «Локальные изменения» и нажмите Ctrl + K или нажмите «Фиксация» на панели инструментов.

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

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

   Вы также можете выбрать файлы в узле «Неверсированные файлы» — PyCharm подготовит и зафиксирует эти файлы за один шаг.

3. Введите сообщение фиксации.

   Можно щелкнуть История сообщений фиксации Ctrl + M , чтобы выбрать из списка последних сообщений фиксации.

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

   Вы можете настроить правила сообщений фиксации в диалоговом окне «Настройки / Предпочтения». Ctrl + Alt + S в разделе «Контроль версий | Диалог фиксации. Также есть быстрое исправление и действие «Переформатировать», которое переносит длинную строку или переформатирует сообщение.

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

   • Автор: если вы фиксируете изменения, сделанные другим человеком, вы можете указать автора этих изменений.

   • Исправить фиксацию: позволяет добавлять локальные изменения в последнюю фиксацию.

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

     Когда этот параметр включен, в конец сообщения о фиксации автоматически добавляется следующая строка: Подписано: <имя пользователя>

   • В области Перед фиксацией выберите действия, которые PyCharm должен выполнить перед фиксацией выбранного файлы в локальный репозиторий.

   • В области «После фиксации» вы можете выбрать конфигурацию доступа к серверу или группу серверов, которые будут использоваться для загрузки зафиксированных файлов на локальный или удаленный хост, смонтированный диск или каталог. См. Подробности в разделе «Развертывание».

5. Когда вы будете готовы, нажмите «Принять» или щелкните стрелку на кнопке «Принять», чтобы отобразить доступные параметры:

   • Принять и нажать ( Ctrl + Alt + K ): нажмите на изменения в удаленный репозиторий сразу после фиксации.Вы сможете просмотреть текущую фиксацию, а также все другие фиксации, прежде чем они будут отправлены на удаленный компьютер.

   • Создать исправление: создание исправления на основе изменений, которые вы собираетесь зафиксировать. В диалоговом окне Create Patch введите имя файла патча и укажите, нужен ли вам обратный патч.

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

Зафиксировать часть файла

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

PyCharm позволяет фиксировать такие изменения отдельно одним из следующих способов:

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

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

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

Выберите фрагменты, которые вы хотите зафиксировать

1. Откройте вертикальное окно инструмента фиксации Alt + 0 слева или вызовите диалоговое окно «Принять изменения».

2. Чтобы отобразить различия между версией репозитория и локальной версией выбранного файла, в окне инструмента фиксации щелкните на панели инструментов или нажмите Ctrl + D .

   Если вы используете диалоговое окно «Принять изменения», нажмите «Разница».

3. Установите флажок рядом с каждым фрагментом измененного или вновь добавленного кода, который вы хотите зафиксировать, и оставьте другие изменения невыделенными:

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

   Чтобы назначить настраиваемый ярлык для этого действия: в диалоговом окне «Настройки / Предпочтения» Ctrl + Alt + S выберите «Раскладка» и найдите действие «Переместить строки в другой список изменений» в разделе «Системы контроля версий».

4. Щелкните «Принять». Невыбранные изменения останутся в текущем списке изменений, так что вы можете зафиксировать их отдельно.

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

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

   Если в желобе нет маркеров изменений, убедитесь, что параметр «Выделить измененные линии в желобе» включен в диалоговом окне «Настройки / Предпочтения» Ctrl + Alt + S ниже.

2. На появившейся панели инструментов выберите целевой список изменений для измененного фрагмента кода (или создайте новый список изменений):

3. Зафиксируйте каждый список изменений отдельно.

Отправка изменений в удаленный репозиторий

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

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

1. Выполните одно из следующих действий:

   • Чтобы протолкнуть изменения из текущей ветви, нажмите Ctrl + Shift + K или выберите VCS | Git | Нажмите из главного меню.

   • Чтобы отправить изменения из любой локальной ветки, имеющей удаленный компьютер, выберите эту ветвь во всплывающем окне «Ветви» и выберите «Отправить» из списка действий.

   Откроется диалоговое окно «Push-коммиты», в котором будут показаны все репозитории Git (для проектов с несколькими репозиториями) и перечислены все коммиты, сделанные в текущей ветке в каждом репозитории с момента последнего нажатия.

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

   Вы можете нажать Ctrl + Q для выбранной фиксации, чтобы отобразить дополнительную информацию, такую ​​как автор фиксации, время, хэш и сообщение фиксации.

2. Если в репозитории нет пультов ДУ, появится ссылка «Определить удаленный». Щелкните эту ссылку и укажите удаленное имя и URL-адрес в открывшемся диалоговом окне. Он будет сохранен, и вы сможете отредактировать его позже через VCS | Git | Пульты (подробности см. В разделе Добавление удаленного репозитория).

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

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

   Вы также можете переключиться в режим редактирования, нажав Введите или F2 для выбранного элемента.

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

   Если автор фиксации отличается от текущего пользователя, эта фиксация помечается звездочкой.

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

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

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

   Эти варианты выбора доступны только в том случае, если текущая ветвь не указана в поле Защищенные ветки (см. Параметры управления версиями: Git), в противном случае вы можете выполнить только операцию push .

Обновите вашу рабочую копию, если push отклонен

Если push отклонен, потому что ваша рабочая копия устарела, PyCharm отображает диалоговое окно Push Rejected при условии, что параметр Auto-update if push of the current branch was rejected в Git страница настроек диалогового окна «Настройки» не выбрана. Сделайте следующее:

сек.

1. . Если в вашем проекте используется несколько репозиториев Git, укажите, какие из них вы хотите обновить.Если вы хотите обновить все репозитории, независимо от того, был ли для них отклонен push, выберите опцию Обновить и не отклоненные репозитории. Если этот параметр отключен, будут обновлены только затронутые репозитории.

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

   После того, как вы покинете это диалоговое окно, будет установлен флажок «Автоматически обновлять, если нажатие текущей ветки было отклонено» на странице настроек Git диалогового окна «Настройки», и примененный метод обновления станет методом по умолчанию.

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

3. Выберите метод обновления (перебазировать или объединить), щелкнув соответственно кнопку Rebase или Merge.

Когда мне нужно использовать принудительное нажатие?

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

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

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

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

• Никто не вытащил вашу ветку и не внес в нее некоторые локальные изменения

• Все ожидающие изменения были зафиксированы и нажата

• У вас есть последние изменения для этой ветки

Последнее изменение: 11 ноября 2020 г.

Зафиксировать файл | Задержка

1
git-commit

Попробуйте Git с Backlog

• Git Tutorial

• Изучите основы Git
• Что такое git?
• Рабочий процесс Git
• Создание репозитория
• Запись изменений
• Отмена изменений
• Синхронизация репозиториев
• Перезапись истории

• Обучение Git Collaboration

00 Удаленные ветки

• Использование веток
• Удаленное переключение веток
• Получить удаленную ветку
• Отправить ветку на удаленную
• Рабочие процессы ветвления
• Пример рабочего процесса ветки функций
• Интеграция ветвей
• Ветка слияния
• Перебазировать ветку
• Теги
• Запросы на извлечение

• Работа с G
  • Установить git
  • Параметры по умолчанию
  • Создать репозиторий
  • Зафиксировать файл
• Репозитории
  • Создать удаленный репозиторий
  • Отправить в удаленный репозиторий
  • Клонировать удаленный репозиторий
  • Отправить из клонированный репозиторий
  • Извлечь из репозитория
  • Сделать конфликт
  • Разрешить конфликт
• Ветвление
  • Создать ветвь
  • Переключить ветки
  • Объединить ветки
  • Удалить ветки
  • Работать параллельно
  • Работать параллельно конфликт слияния
  • Перебазировать ветку
• Тегирование
  • Добавить тег
  • Удалить тег
• Перезаписать историю
  • Применить — изменить
  • Отменить
  • Сбросить
  • 9264 9264 Cherry pick

  .

  No related posts.