Как посмотреть изменения в файле git
Обновлено: 06.07.2024
Git очень удобная система контроля версий, которая сейчас используется практические повсеместно. Она нужна для того, чтобы команды могли кооперироваться в создании программного продукта и совмещать код написанный разными людьми в одном репозитории.
Когда я учил Git мне говорили, что в работе мне понадобятся всего 3 команды:
Правда, по сути мне немного слукавили, нужен был ещё как минимум:
Однако, на этом все мои теоретические знания по Git заканчивались и достаточно долгое время я пользовался только этими командами, покуда в один момент не начал работать над веб-приложениями, над которыми со мной работали ещё несколько человек.
Там мне объяснили какие команды также нужны в разработке, зачем они используются и как часто они используются. Сегодня я решил поделиться этими командами с вами.
Основная терминология
отслеживаемые файлы - когда файл добавляется в отслеживание Git'а создается специальный кэш, благодаря которому можно будет откатываться к предыдущим версиям файла
неотслеживаемые файлы - когда файл не добавляется в отслеживание Git'а его кэш не хранится в Git'е, а значит откат на предыдущие версии не работает для таких файлов
коммит - специальное название сохранения версии. Таким образом мы называем все изменения в файлах одним именем и сможем перемещаться между коммитами
откат - переход на предыдущий коммит и отмена изменений с текущего коммита до того, на который мы хотим вернуться
пуш - отправка изменений на удаленный репозиторий (в Github, Gitlab, BitBucket)
фетч - скачивание изменений из репозитория
ветка - ветки создают, когда нужно несколько активных вариантов разработки. В основном их используют для того, чтобы быстро разработать некоторый функционал, а потом слить ветки в одну
мердж - слитие веток в одну
Работа с Git
Прежде всего нам понадобятся команды для работы с файлами. Знать add конечно хорошо, но нужно иногда и удалять что-то из кэшируемых файлов или изменять поведение Git для определенных файлов. Сегодня я разберу некоторые команды, которые позволят вам манипулировать с файлами, ветками, коммитами в Git.
init
Данная команда инициализирует систему контроля версий. Для того чтобы создать новый репозиторий достаточно просто ввести:
clone
Данная команда нужна для того, чтобы клонировать репозиторий из облака. Можно клонировать репозитории из Github, Gitlab, BitBucket и других сервисов. Для того чтобы склонировать репозиторий нужно ввести:
add
Данная команда понадобится вам, когда вам нужно добавить файл для кэширования. Давайте разберёмся как это работает:
Вы изменяете файлы, можете изменять достаточно много файлов, задачи изменения которых вообще никак не связаны
Вы решаете "закоммитить" ваши файлы (сделать сохранение версии, для того чтобы Git запомнил все ваши изменения в файлах и как-то назвал их, для этого есть отдельная команда git commit )
Вы также можете добавить файлы, которые ранее не отслеживались, для того чтобы Git занёс их в свою систему хранения версий и вы могли откатываться на какую-то из версий файла
Обычно с самого начала все разработчики делают коммит (сохранение версии) с названием init , занося все файлы в систему отслеживания. Делается это с помощью простой последовательности команд:
Проделав данный алгоритм, состоящий из двух команд вы занесёте все файлы из вашего проекта в систему контроля версий Git.
Но, что если вам не хочется вносить все файлы? Тогда вы может использовать следующий синтаксис:
Так, хорошо, но что если нам нужно занести весь проект в систему отслеживания, однако есть пару директорий, которые мы не хотим заносить (например, node_modules или out )? Для этого мы можем создать файл .gitignore , в котором будут прописаны пути до файлов и директорий, которые Git должен игнорировать:
В данном случае Git будет игнорировать директорию node_modules , out и файл one_file.tsx
Также мы можем сделать так, чтобы Git искал некоторые названия в дочерних директориях и игнорировал их:
Данный пример говорит о том, что Git будет игнорировать директорию node_modules , которая будет находится в любой дочерней директории (включая корневую).
Больше о .gitignore можно прочитать здесь
А что если я хочу обновить уже закэшированные файлы, мне что теперь их писать по одному? Конечно же нет. Для этого существует специальный флаг -u (сокращение от --update ), который позволяет закэшировать только те файлы, которые уже отслеживаются:
rm
Данная команда поможет, когда нам нужно избавиться от файла, она подобно команде rm удаляет файл из файловой системы и кэша Git, позволяя нам быстро избавиться от файла.
Данный пример удалит файл file.txt из кэша и файловой системы.
Но, что если мы добавили файл, который нам более не нужен в кэше, но нужен в файловой системе? Тогда мы можем воспользоваться следующей командой:
Данная команда удалит файл из "кэша", но что это значит? Допустим, что мы "закоммитили" (сохранили версию, об этом поговорим вот уже совсем скоро) наш файл, а теперь хотим, чтобы Git считал что мы его удалили, а сами просто оставили его на диске. Для этого и нужна команда выше. Она просто говорит Git: "Слушай, а давай ты просто удалишь этот файл из кэша и не будешь его показывать в репозитории, а я оставлю копию у себя на ПК, ок?"
Таким образом мы можем работать с данным файлом и Git не будет знать что именно в нём мы изменяем, а затем просто можем опять добавить его. Файл будет висеть в состоянии "untracked" (не отслеживается) до тех пор, покуда мы его опять не добавим.
commit
Думаю, что стоит поговорить об этом уже сейчас, ибо позже без данной команды уже никуда. Данная команда буквально сохраняет версию, в которой указывается что именно в файлах мы изменили.
Обычно разработчики сохраняют версию программы с помощью данной команды:
В данном случае мы просто скажем, чтобы Git сохранил все изменения, которые мы сделали в файлах, которые отслеживаются. Файлы, которые не отслеживаются просто не попадают в версию, а также их изменения никак нельзя отследить.
Для того чтобы отменить последний коммит (отменить не изменения, а именно просто разкоммитить изменения) и совместить его с текущими изменениями используйте команду:
show
Данная команда нужна для того, чтобы быстро показать что было сделано за предыдущие коммит:
Выведутся изменения следующим образом:
status
Если до этого момента вы не знали как проверить какой файл кэшируется, какой не отслеживается, а какие файлы и вовсе только что были удалены из кэша, то спешу вас обрадовать, у вас теперь есть команда git status , которая даёт возможность посмотреть что именно происходит с вашими файлами:
Если вы хотите узнать более подробно о том, что же именно случилось с вашими файлами, то можете добавить ключ -v (сокращение от --verbose - внимательно):
Если же вам наоборот хочется увидеть бриф по информации, то добавьте флаг -s (сокращение от --short ):
log
До этого момента мы могли только посмотреть что творилось в предыдущем коммите, однако с помощью git log мы можем посмотреть историю наших коммитов:
Если же вы хотите красиво вывести все ваши коммиты в столбик, то используйте данную команду:
В данной команде мы описываем что хотим просматривать коммиты и их названия в одну строку, хотим чтобы коммиты сокращали свой ID, а также чтобы всё это красиво было разбито по списку
diff
С помощью данной команды мы можем посмотреть на изменения между коммитами. Эта комманда является одной из самых мощных в Git, вам стоит обратить на неё внимание:
Так называемые "ID-коммита" можно взять и вышеприведенной git log
Также, можно посмотреть что было изменено с момента последнего коммита (что изменено и попало в кэш) с помощью флага --cached :
Если вы хотите посмотреть историю изменений в файлах в определенном коммите, то используйте следующую команду:
Если вы хотите посмотреть на статистику, то вы всегда можете использовать флаг --stat :
Если вы хотите посмотреть на изменения только тех файлов, которые добавлены для отслеживания, то нужно ввести следующую команду:
branch
В Git есть ветки для разделения версий. Если коммит нужен для того, чтобы сделать snapshot (слепок изменений) файлов, то ветки нужны для того, чтобы эти snapshot'ы разделять. У вас может быть ветка
любое другое название
Для того чтобы перечислить все ветки с помощью Git нужно ввести следующую команду:
Для того чтобы создать новую ветку нужно ввести:
checkout
Checkout используют для того, чтобы переходить между ветками. Для того чтобы перейти на другую ветку достаточно просто написать:
Для того чтобы создать ветку и сразу же перейти на неё достаточно ввести:
merge
Соединение веток не являются сложной темой. Для того чтобы слить текущую ветку с другой нужно ввести:
push
Для того чтобы закинуть изменения на сервер нужна комнда push , которая позволит нам закинуть текущую ветку на удаленный репозиторий:
В завершение
Здесь мы чуть более глубже познакомились с основами Git, поняли как работать с ветками, как их мерджить, как коммитить файлы, смотреть изменения, а также как показывать последние коммиты.
Если вы хотите больше узнать о веб-разработке, а также о линуксе, то милости прошу в мой блог на телеграм.
Надеюсь данная статья помогла вам чуть лучше узнать Git. Хорошего дня и продуктивной недели!
Видеоурок. Часть 1. Практика, основы работы с коммитами и историей коммитов
Видеоурок. Часть 2. Практика, дополнительные приемы и фишки
Видеоурок. Часть 3. Общие наблюдения и советы. Как делать "хорошие" коммиты
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое коммит
По-научному это сохранение состояния, фиксация или слепок изменений.
Чуть менее научно, коммит - зафиксированный набор изменений, который показывает, какие файлы изменились и что именно в них изменилось. Рассмотрим на примере.
Как сделать коммит
Представим, что мы добавляем блок учеников на сайт. Добавляем новую разметку в index.html и новые стили в main.css. Чтобы сохранить изменения, нужно их закоммитить. Но предварительно сообщить git, какие именно файлы мы хотим положить в коммит. Команда git add добавляет (или подготавливает) файлы к коммиту. Можно добавить файлы по отдельности, вот так
А можно все сразу
Добавлять все файлы сразу удобно, но стоит всегда внимательно проверять, точно ли мы хотим добавить в коммит все измененные файлы. Если ошиблись и какой-то файл добавлять в коммит не нужно, то можно исключить этот файл из подготовленных.
Создаем сам коммит
Состояние файлов в git. Измененные и подготовленные файлы
Измененные файлы - это те файлы, которые мы успели изменить с момента последнего коммита
Подготовленные файлы отличаются от измененных тем, что они "подготовлены" к коммиту, то есть будут добавлены в следующий коммит.
git add filename добавляет или подготавливает файл к коммиту.
git reset filename удаляет файл из подготовленных к коммиту.
Содержимое файлов при этом не меняется. Один файл может одновременно находиться и в измененных, и в подготовленных. Это происходит, если мы добавили файл, но не закоммитили и продолжили делать в нем измения.
Из чего состоит коммит
Каждый коммит имеет
Как добавить файлы и сделать коммит одной командой
git commit с флагом -a добавит все файлы и создаст коммит. Но осторожно, не увлекайтесь этим, потому что по ошибке легко включить в коммит лишние файлы.
Отслеживаемые и неотслеживаемые файлы
Отслеживаемые файлы - это те, в которых git отлавливает изменения и показывает их через git status и git diff. В нашем проекте файлы index.html и css/main.css - отслеживаемые.
Неотслеживаемые файлы - это файлы, изменения в которых git не отлавливает. Новый файл в проекте по умолчанию попадает в неотслеживаемые. Добавить новый файл в рабочую область git можно командой git add filename
История коммитов, git log
Все коммиты можно посмотреть в истории коммитов. История хранит все данные обо всех коммитах проекта. Показывается история командой
История включает в себя все сведения о коммитах: хэш, автор, дата и список изменений. Список изменений смотреть командой git show по хэшу коммита
Переименование последнего коммита, git commit --amend
Если коммит успели запушить, то переименовывать коммиты нужно осторожно, как именно - во второй части курса.
Откат коммитов, git revert
Если мы сделали неверный коммит и хотим откатить изменения, сделанные в нем, то поможет команда git revert
При этом откроется дефолтный текстовый редактор, который предолжит ввести commit message. Если мы хотим оставить commit message по умолчанию, то можно обойтись без открытия редактора с помощью флажка --no-edit
Работа с файлами
При работе с файлами нужно учесть, что новые файлы git отправляет в неотслеживаемые. Поэтому при добавлении нового файла стоит сначала его закоммитить, а потом вносить изменения, чтобы они были доступны через git diff
При обычном переименовании файла в файловом менеджере или командой mv git сначала показывает 2 файла: старый удаленный и новый неотслеживаемый. Чтобы git понял, что этот файл именно переименованный, нужно сначала добавить эти файлы в подготовленные к коммиту
Тогда при команде git status файл будет отображаться именно как переименованный
Можно избежать этого промежуточного состояния, если переименовать файл в командной строке таким образом
Тогда файл будет сразу отображаться, как переименованный. То же самое с удалением файла
Командная строка vs IDE
Работа в PhpStorm продемонстрирована в первых двух частях видео.
Как и в прошлом уроке мы видим, что некоторые вещи удобнее делать в IDE. Например, процесс добавления файлов (git add) в PhpStorm при создании коммита почти не привлекает внимания. Но важно понимать, что такое git add и зачем он нужен. И что любая IDE под капотом все равно выполняет базовые команды git. Просто для нас предоставляется удобная обертка, чтобы мы больше сосредоточились на самом проекте, а не на git.
Наблюдения и советы при работе с коммитами
В каждой команде свои правила и соглашения. Но я приведу общие советы и размышления, которые помогут в любом проекте
- коммит - это законченный функционал
- всегда проверяйте перед коммитом, что в него попадет. git diff - наш лучший друг
- выделяйте мелкие баги и правки в отдельные коммиты
- маленький коммит в одну строку - это нормально
- видите много изменений - подумайте, можно ли разбить их на отдельные коммиты
- мыслите задачей, а не файлами. Выделяйте полезное действие коммита
- commit message говорит, ЧТО делает коммит, а не КАК делает
- коммит-рефакторинг - это нормально. Не стоит мешать его с другими задачами
- git плохо работает с бинарниками (картинками, pdf, видеофайлами) - видит факт изменения, но не сами изменения
- подписывайте коммит так, чтобы можно было проследить историю развития проекта
Все эти правила одновременно соблюсти довольно трудно. Это приходит с опытом, но главное - полагаться на здравый смысл. Умение хорошо формировать и подписывать коммиты - один из признаков хорошего разработчика.
Используйте удобные инструменты в IDE, но не забывайте командную строку. В ней вы лучше будете понимать, как устроен git, как он работает
Хорошие и плохие коммиты
С точки зрения git коммиты не бывают плохими и хорошими. Но есть удачные и неудачные подписи к коммитам с точки зрения наших коллег. Несколько примеров
Изменен файл index.html
Добавлен блок новостей
В первом коммите непонятно, что он делает, во втором - ясно описана задача
Изменены стили баннера
Растянули баннер на всю ширину окна
Первый коммит говорит только об изменениях стилей баннера, второй - точно, что именно изменено. Больше информации
Добавлен файл VipClient
Работа с vip-клиентами вынесена в отдельный класс
По первому коммиту можно предположить, что в VipClient мы скорее всего работаем с ВИПами. Во втором коммите это точно понятно, плюс дополнительная информация, что это отдельный класс.
Поправлены стили в main.css
Рефакторинг стилей в main.css
Первый коммит говорит о правке стилей, но непоянтно, что именно поправлено. Бага? Новые значения? Изменен цвет текста по рекомендации дизайнера? Второй коммит ясно указывает, что это рефакторинг
Маленький фикс
Исправлена опечатка в заголовке title страницы "О компании"
Коммит "маленький фикс" даже приблизительно не говорит, в чем он заключается. Второй коммит дает полное представление
Немного о философии коммитов
Концепция коммитов заставляет если не менять подход к разработке, то по-другому к ней относиться. С git нам приходится не просто писать код, а планировать его написание. Планировать задачи, над которыми мы работаем. Декомпозировать задачи, то есть разбивать их на небольшие части.
Мы больше думаем о том, что мы работаем не одни, а в команде. История коммитов общая для всего проекта. Чем лучше мы научимся формировать и подписывать коммиты, тем легче будет ориентироваться в истории нам самим и нашим коллегам.
В любом проекте важны не только код и его структура, но и история коммитов и хорошие commit message.
На этом все. В следующем уроке мы будем больше работать с историей коммитов и посмотрим различные варианты использования команды git log
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Создаем тестовый сайт и инициализируем репозиторий
С этого момента мы будем проходить уроки на примере тестового сайта site-git. Проект содержит три файла: index.html, css/main.css и .gitignore. По мере прохождения уроков будем понемногу расширять сайт, вносить изменения и добавлять новые файлы.
Гнаться за красотой не будем, сайт очень простой. Главное, сосредоточиться на сути, поэтому верстки и стилей будет минимум. Даже если вы не знакомы с html и css, то легко разбересь в нашем простом примере.
Создайте на github новый приватный репозиторий site-git. Скачайте архив с файлами сайта и распакуйте содержимое в папку site-git
Обратите внимание на .gitignore
Кроме index.html и main.css в архиве лежит еще скрытый файл .gitignore. Это файл, в котором прописаны папки и файлы, которые git не отслеживает. Подробнее о .gitignore мы поговорим во второй части курса
Теперь все приготовления сделаны, приступим к изменениям в проекте.
Вводная
Когда мы работаем над проектом, то делаем много изменений в разных файлах. Эти изменения легко потерять или запутаться в них.
Git позволяет легко отслеживать все изменения, видеть добавленные и удаленные файлы в проекте, а также изменения в самих файлах. Если мы изменим хоть один символ в коде, git заметит это изменение и уже не потеряет. Команды git status и git diff (от слова difference - разница) позволяют отслеживать все изменения в проекте.
git status
Эта команда показывает список измененных файлов
Также git status выводит некоторую дополнительную информацию, которую мы изучим позже.
В PhpStorm - окно Version Control (Вызов окна - Alt+9)
git diff
Это команда для просмотра изменений в файлах. В терминале мы видим добавленные и удаленные строки. То есть если в строке изменился хоть один символ, то git diff покажет 2 строки: одну удаленную, другую - добавленную.
Просмотр всех изменений
Просмотр изменений в отдельном файле
Изменения в PhpStorm
В онке Version Control мы сразу видим список измененных файлов. Чтобы посмотреть изменения в конкретном файле, нужно кликнуть на него и нажать Crtl+D (diff). В окне difference видны не только добавленные и удаленные строки, но и изменения в отдельных строках.
Плюсы PhpStorm
- список измененных файлов можно держать открытым, не обязательно набирать git status
- измененные строки видны сразу же в редакторе кода
- просмотр изменений визуально нагляднее, чем в терминале (показываются даже изменения в отдельных строках)
- проще откатить отдельные изменения
PhpStorm отлично интегрируется с git. Конечно, не он один. Некоторые продвинутые редакторы кода тоже могут работать с git. Вы можете посмотреть, как реализована поддержка git, например, в sublime, но это далеко не так удобно, как в IDE от JetBrains. Это не реклама, а просто совет использовать удобные инструменты.
PhpStorm платная программа (9 $/месяц на январь 2020 года), но это затраты, которые окупятся. Рекомендую.
Поддержка git в Sublime Text 3
В Sublime Text 3 ситуация несколько изменилась - поддержка git улучшилась. Подробнее рассмотрим работу с git в sublime во второй части курса
На этом все. В конспекте информации мало, только основные команды, поэтому смотрите видеоурок. Там все нагляднее и понятнее.
В следующем уроке мы познакомимся с коммитами и научимся с ними работать.
В этой статье мы обсудим разные Git-команды, которые могут оказаться полезными для разработчика или специалиста по Big Data. Вы узнаете, как проверять, удалять и приводить код в порядок. А еще рассмотрим способы выхода из Vim и экономию времени с помощью псевдонимов Bash и конфигурации редактора Git.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Проверяем все и вся
- git diff— Посмотреть все изменения файла локально. При указании имени файла изменения будут показаны только для него.
- git log — Просмотреть историю коммита. Может также использоваться для файла с git log -p my_file. Введите q, чтобы выйти.
- git blame my_file — Просмотреть, кто, что и когда изменил в my_file.
- git reflog — Показать журнал изменений в заголовке локального репозитория. Отличный вариант для поиска утраченных данных.
Вернуть, как было
- git reset, git checkout и git revert — команды, которые используются, чтобы отменить какие-либо действия. Но они не такие и простые, с ними надо уметь обращаться.
- git reset, git checkout могут использоваться как для коммитов, так и для обычных файлов.
- git revert используется только для работы с коммитами.
Если вы работаете в коллективе и коммиты общие, тогда ваш выбор — git revert.
У каждой команды есть целый набор опций. Вот наиболее употребляемые:
git reset --hard HEAD — отмена проиндексированных и непроиндексированных изменений с момента последнего коммита.
Указываем вместо HEAD определенный коммит, чтобы отменить изменения, произошедшие после него. --hard отбрасываются оба типа изменений, о которых говорилось выше.
Не забывайте убедиться в том, что вы не отменяете коммит из опубликованной ветки, от которой зависят другие члены команды.
HEAD часто используется для my_commit, чтобы отменить изменения в вашем локальном рабочем каталоге с момента последней фиксации.
checkout лучше всего использовать для локальных отмен. В этом случае коммиты из удаленной ветки, от которой зависят ваши коллеги, не будут затронуты!
Если вы используете checkout с веткой вместо коммита, HEAD переключается на указанную ветвь, а рабочий каталог обновляется для соответствия изменениям. Это самое распространенное использование этой команды.
git revert my_commit — отмена последствий изменений в my_commit. revert выполняет новый коммит после отмены изменений.
revert безопасен для общих проектов, поскольку команда не перезаписывает изменения, от которых могут зависеть другие ветки.
Иногда вы просто хотите удалить неотслеживаемые файлы в вашем локальном каталоге. К примеру, запустив какой-то код, который создал много разных типов файлов, которые вам не нужны. К сожалению. Clean поможет мгновенно удалить их!
git clean -n — удаление неотслеживаемых файлов в локальной рабочей директории.
-n — флаг для пробного запуска, ничего не удаляется.
-f — флаг для удаления файлов.
-d — флаг для удаления неотслеживаемых директорий.
По умолчанию неотслеживаемые файлы .gitignore не будут удалены, но это можно изменить.
Наводим порядки
git commit --amend — добавляем поэтапные изменения в последний коммит.
git push my_remote --tags — отправка локальных тэгов в удаленный репозиторий. Хороший вариант для присвоения версий изменениям.
Помогите, я застрял в Vim и не могу выбраться!
Git в некоторых случаях открывает сессию редактора Vim. И если вы не слишком хорошо знакомы с ним, то можете оказаться в затруднительной ситуации. Да и не только вы — к примеру, на Stack Overflow более 4 тысяч пользователей хотят знать, как выбраться из Vim.
Вот четырехэтапный план, который поможет закрыть Vim и сохранить изменения:
Изменяем редактор по умолчанию.
Вы можете избавиться от Vim совсем, если смените редактор по умолчанию. Вот команды для работы с популярными редакторами. Пример выбора другого редактора, в нашем случае Atom:
git config --global core.editor «atom --wait»
Ярлыки для команд Git
А вот способ, который позволяет добавлять ярлыки для Git-команд, для вашего .bash_profile.
Больше информации о .bash_profile можно получить здесь.
Что касается способа, приведенного выше, то теперь вы можете использовать gs вместо git status.
Собственно, это все на сегодня. Если есть возможность, укажите в комментариях, какие Git-команды используете вы и почему.
Читайте также: