Github actions как ci/cd для сайта на статическом генераторе и github pages

Содержание

Скрывайте локальные изменения, когда не хотите их «вливать»

А теперь про то, когда Вы не хотите чтобы отслеживались изменённые файлы. Яркий пример: очень многие, особенно долгоживущие репозитории, хранят в себе ряд конфигов. Часто они служат для обеспечения единообразия настроек (к примеру, ) или тасков сборки/линтинга (). И иногда так случается, что хочется их как-то изменить, но возможность разделения конфигов на «общие» и «пользовательские» отсутствует.


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

С этих пор он «пропадает с радаров» даже если Вы продолжите его изменять. Если во время -а приходят новые изменения в этом же файле — в этом случае он будет продолжать считаться неизменённым, но легко смержиться Вам не даст. Чтобы вернуть всё как было, надо снять флаг, добавив :

Основные термины VCS

Коммиты (commit)

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

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

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

Перво-наперво, Юлия должна выполнить апдейт (update) своего локального репозитория – синхронизироваться с сервером и получить последнюю на данный момент версию ПО. Для этого выполняется соответствующая команда.

Затем Юля занимается разработкой модуля для фильтрации изображении.

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

  1. Выполняется команда коммит (commit). Коммит – это сохранение изменений в проекте. Он обязательно должен сопровождаться текстовым комментарием разработчика о том, какая работа была проделана, и что изменено, либо написано. Коммит поможет другим разработчикам легче разобраться в чужом коде. Кроме того, по коммитам выполняется откат к предыдущей версии проекта, если вдруг что-то было сделано неправильно, либо с фатальными ошибками. Коммит фиксируется в локальном репозитории.
  2. Затем нужно синхронизировать локальный коммит с облаком и запушить (push) все изменения на сервер. Выполняется команда push.

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

Конфликты

Конфликты возникают во время операции push, когда оказывается, что два разработчика работали над одним и тем же кодом. Что и понятно.

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

Ветки (branch)

Рассмотрим создание веток опять же на примере проекта “графический редактор”.

Части команды дано задание начать разработку версии 2.0 графического редактора (например, предполагается поддержка работы с векторными изображениями).

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

В данной ситуации делается следующее: выделяется ветка (бранч, branch). Создание branch – это создание копии текущего репозитория. Дальнейшая разработка в рамках новой ветки никак не будет затрагивать начальную основную ветку проекта (которая называется master).

Разработка в рамках новой ветки идентична разработке основной ветки. Коммиты, push – это всё на месте.

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

На этом всё! До встречи на vscode.ru!

Из следующих статей на тему работы с GitHub Вы узнаете:

  • Про регистрацию на GitHub
  • Как пользоваться GitHub

Как проанализировать рынок фотостудий с помощью Python (3/3). Аналитика

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

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

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

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

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

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

Вебинар «Простая и понятная производственная аналитика с дашбордом Winnum»

25 августа в 11:00 в 11:00, онлайн, беcплатно

tproger.ru

События и курсы на tproger.ru

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

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

Что такое Hub?

Если Git — это сердце GitHub, то Hub — это его душа. Концентратор в GitHub — это то, что превращает командную строку, такую ​​как Git, в крупнейшую социальную сеть для разработчиков.

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

Репозиторий

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

Ветка

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

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

Запрос на извлечение

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


Следуйте приведённым ниже инструкциям, чтобы создать запрос на извлечение в GitHub:

  1. Перейдите в хранилище и найдите ветку меню
  2. В меню выберите ветку, которая содержит ваш коммит
  3. Нажмите кнопку Новый запрос на извлечение рядом с меню ветки
  4. Вставьте заголовок и описание для вашего запроса.
  5. Нажмите кнопку Создать запрос на извлечение

Форкинг репозитория

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

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

Следуйте приведённым ниже инструкциям, чтобы создать репозиторий в GitHub:

  1. Найдите репозиторий, который вы хотите разветвлять
  2. Нажмите кнопку Форк

GitHub не ограничен только для разработчиков

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

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

Готовы начать?

Продвинутое использование: правим историю

Для большего контроля над историей коммитов локальной ветки можно использовать команду , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

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

Измененяем сообщение коммита/разбиваем коммиты

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

После завершения редактирования введите .

Перезапись нескольких коммитов

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

Объединение нескольких коммитов

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

Переносим отдельный коммит

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

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

У меня есть файлы, но я не знаю, что с ними делать!

А вот здесь все предельно просто — работу за вас сделает GitHub!

Если у вас есть файлindex.html, то GitHub сразу поймет, что от него хотят.

Теперь самое время переключиться на GitHub Pages. Зайдите в свой GitHub-репозиторий и нажмите Settings.

Прокрутите до GitHub pages. Здесь вы увидите следующее:

Теперь в выпадающем меню Source выберите master branch или master branch/docs folder. Разница вот в чем: если вы будете размещать проект из папки docs, то эта папка (docs) обязательно должна присутствовать в ветке master, из которой запускается сайт!

Если вы совсем новичок, то, скорее всего, выберете master branch. То есть репозиторий будет размещен «как есть».

Далее следует уведомление, что сайт готов к размещению.

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

Кликните по этой ссылке.

А вот и ваш бесплатный сайт!

Поздравляем!!!

Теперь попробуем создать сайт с нуля.

Как проанализировать рынок фотостудий с помощью Python (1/3). Парсинг данных

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

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

Удалённые серверы

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

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

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

Наиболее употребляемые команды:

  • — добавляет удалённый репозиторий с заданным именем;
  • — удаляет удалённый репозиторий с заданным именем;
  • — переименовывает удалённый репозиторий;
  • — присваивает репозиторию с именем новый адрес;
  • — показывает информацию о репозитории.

Следующие команды работают с удалёнными ветками:

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

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

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

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

Слияние

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


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

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

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

Перемещение

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

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

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

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

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

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

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

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

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

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

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

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

Система контроля версий Git

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

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

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

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

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

В мире разработки такие программы называют «терминал» или «консоль». А работает это так: мы вводим команду и получаем реакцию машины: сообщение об ошибке, запрос на подтверждение информации, результат выполненных действий.

Устанавливаем Git

Если раньше вы не работали с Git, сперва его нужно установить. Способы зависят от операционной системы вашего компьютера.

Установка в Linux

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

  • Если у вас 21 или более ранняя версия Fedora, используйте .
  • Для 22 и последующих версий Fedora вводите .
  • Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте .

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

Установка на macOS

  1. Скачиваем Git со страницы проекта.
  2. Запускаем загруженный файл.
  3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
  4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
  5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.

Проверим, что Git установлен

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

Настройка Git

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

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

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

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

Подайте мне вот этот проект!

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

Для клонирования репозитория на компьютер перейдите в репозиторий на GitHub и нажмите большую зеленую кнопку под названием Clone or download (разумеется, вы можете просто скачать репозиторий и избежать всех заморочек с терминалом. Но я в вас верю, поэтому не будем сдаваться!). Проследите, чтобы появилась надпись Clone with HTTPS. Теперь нажмите на иконку буфера обмена для копирования-вставки (либо выделите ссылку и скопируйте ее).

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

Откройте терминал и перейдите в директорию для копирования репозитория. Например, для перехода на Рабочий стол напечатайте вот это:

cd Desktop

Затем клонируйте туда репозиторий по следующей команде:

git clone <то,_что_вы_только_что_скопировали>

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

Новый GitHub-репозиторий, склонированный на рабочий стол, готов! Данная команда создает точную копию репозитория в вашей системе. Здесь вы сможете с ним работать, редактировать, индексировать изменения, создавать коммиты с изменениями и отправлять их на GitHub.


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

Добавляем файлы в проект

Вот, чем мы займемся:

git statusgit addgit commit -m “ “git push

Но ничего сложного здесь нет!

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

Проверьте статус проекта.

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

git status

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

git add <имя_файла>

Либо все сразу:

git add — all

или даже:

git add .

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

Процесс создания коммитов с изменениями начинается с выполнения команды:

git commit -m “<сообщение_о_коммите>”

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

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

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

git push

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

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

Итог: у вас есть свой GitHub репозиторий, вы научились добавлять и изменять в нем файлы.

  • Как писать Bash-однострочники для клонирования и управления GitHub/GitLab репозиториями
  • Top 100 наиболее популярных репозиториев на GitHub
  • Основы Git за 5 минут

Как работает git?

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

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

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

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

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

показывает изменения в каждом коммите;

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

показывает n последних коммитов;

и позволяет отфильтровать коммиты по промежутку времени, например покажет коммиты с 1 января 2019 года;

позволяет указать формат логов (например, ), также можно использовать для большей кастомизации, например ;

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

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

позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток)

Например,  покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).

показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак обозначает коммиты из , а — из .Обратите внимание: используется три точки, а не две;

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

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

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

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

Примечание Не путайте с ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.


С этим читают