Как проиндексировать файлы и сделать коммит одной командой
Обновлено: 07.07.2024
Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс ( git add ), потом «сохраняем» ( git commit ).
Любой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).
Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).
Концепция GIT
Ключ к пониманию концепции git — знание о «трех деревьях»:
- Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
- Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
- Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).
Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.
У всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.
Простейший цикл работ
- Редактирование, добавление, удаление файлов (собственно, работа).
- Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
- Коммит (фиксация изменений).
- Возврат к шагу 1 или отход ко сну.
Указатели
- HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
- ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
- Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
- Теги — простые указатели на коммиты. Не перемещаются.
Настройки
Перед началом работы нужно выполнить некоторые настройки:
Если вы в Windows:
Указание неотслеживаемых файлов
Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.
Консоль
Длинный вывод в консоли: Vim
Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .
Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w .
Видеоурок. Часть 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
Несмотря на одинаковое название, команда git commit не имеет ничего общего с командой svn commit . Этот общеупотребительный термин может запутать новичков в Git, имеющих опыт работы с SVN, поэтому важно подчеркнуть разницу. Разница между git commit и svn commit — это разница между моделью централизованного приложения (SVN) и моделью распределенного приложения (Git). В SVN при выполнении коммита изменения передаются из локального клиента SVN в общий централизованный удаленный репозиторий SVN. В Git репозитории распределены, коммиты снимков состояния выполняются в локальный репозиторий, и для этого совершенно не нужно взаимодействовать с другими репозиториями Git. Позже коммиты Git можно будет передать в любой удаленный репозиторий.
Порядок действий
Не вдаваясь в подробности, Git можно рассматривать как утилиту управления временной шкалой. Коммиты — основные конструктивные элементы временной шкалы проекта Git. Их можно рассматривать как снимки состояния или контрольные точки на временной шкале проекта Git. Коммиты создаются с помощью команды git commit , которая делает снимок состояния проекта на текущий момент времени. Коммиты снимков состояния Git всегда выполняются в локальный репозиторий. В этом и заключается фундаментальное отличие от SVN, где коммит рабочей копии выполняется в центральный репозиторий. Git же, напротив, не принуждает вас взаимодействовать с центральным репозиторием до тех пор, пока вы не будете к этому готовы. Как раздел проиндексированных файлов является буфером между рабочим каталогом и историей проекта, так и локальный репозиторий разработчика является буфером между его вкладом в проект и центральным репозиторием.
Снимки состояния, а не различия
Помимо различий между SVN и Git с практической точки зрения, их базовая реализация также основывается на совершенно разных концепциях проектирования. SVN отслеживает различия в файле, тогда как модель управления версиями Git базируется на снимках состояния. Например, в коммите SVN содержатся различия исходного файла и файла, добавленного в хранилище. А Git записывает в каждом коммите все содержимое каждого файла.
Такой подход позволяет выполнять многие операции в Git намного быстрее, чем в SVN, поскольку конкретную версию файла не нужно «собирать» из его различий — во внутренней базе данных Git находится уже готовая редакция каждого файла.
Модель снимков состояния Git влияет практически на все аспекты модели управления версиями, от инструментов ветвления и слияния до рабочих процессов при совместной работе.
Распространенные опции
Коммит проиндексированного состояния кода. Эта команда откроет текстовый редактор с предложением ввести комментарий к коммиту. После ввода комментария сохраните файл и закройте текстовый редактор, чтобы выполнить коммит.
Выполнение коммита состояния со всеми изменениями в рабочем каталоге. Эта команда включает только изменения отслеживаемых файлов (тех, которые были в какой-то момент добавлены в историю с помощью команды git add ).
Быстрая команда, которая создает коммит с указанным комментарием. По умолчанию команда git commit открывает локально настроенный текстовый редактор с предложением ввести комментарий к коммиту. При передаче параметра -m текстовый редактор не открывается, а используется подставленный комментарий.
Команда для опытных пользователей с параметрами -a и -m . Эта комбинация параметров создает коммит всех проиндексированных изменений и добавляет к коммиту подставленный комментарий.
Этот параметр добавляет команде commit новый уровень функциональности. При передаче этого параметра будет изменен последний коммит. Вместо создания нового коммита проиндексированные изменения будут добавлены в предыдущий коммит. Кроме того, эта команда откроет настроенный текстовый редактор системы с предложением изменить указанный ранее комментарий к коммиту.
Примеры
Сохранение изменений с помощью команды commit
В следующем примере предполагается, что вы изменили содержимое файла hello.py в текущей ветке и готовы сделать коммит в историю проекта. Прежде всего, необходимо проиндексировать файл с помощью команды git add , после чего можно будет сделать коммит проиндексированного снимка состояния.
Эта команда добавит файл hello.py в раздел проиндексированных файлов Git. Проверить результат выполнения команды можно с помощью git status .
Окрашенный зеленым цветом вывод «new file: hello.py » сообщает о том, что файл hello.py будет сохранен при выполнении следующего коммита. Коммит выполняется с помощью указанной ниже команды.
Эта команда откроет текстовый редактор (настраиваемый через git config ) для ввода комментария к коммиту и покажет список файлов, которые будут зафиксированы в этом коммите:
Особых требований для комментариев к коммиту в Git нет, но обычно первая строка содержит описания коммита длиной до 50 символов, затем следует пустая строка и детальное пояснение того, что было изменено. Пример:
Обновление коммита (параметр amend)
Продолжим работу с файлом hello.py из приведенного выше примера. Давайте внесем в файл hello.py новые изменения и запустим следующие команды:
Снова откроется настроенный текстовый редактор. Но на этот раз он будет содержать комментарий к коммиту, который мы уже вводили ранее. Это указывает на то, что мы не создаем новый коммит, а редактируем последний.
Резюме
Модели коммитов в SVN и в Git существенно отличаются, но из-за общей терминологии часто возникает путаница. Если вы начинаете работу в Git, имея опыт работы с SVN, вам будет полезно знать, что коммиты в Git — простая операция, которую следует выполнять часто. В SVN коммит — сложная операция, связанная с выполнением удаленного запроса, тогда как в Git коммиты выполняются локально и по более эффективному алгоритму.
Для разработчика нет, наверное, ничего более увлекательного, чем запуск нового проекта. Начинается он с разработки доменной модели и планирования логики предметной области. Затем происходит создание каркасного представления приложения на стороне клиента и определение того, как оно будет выглядеть в веб-браузере или мобильном устройстве. И, наконец, венчает весь процесс работы над проектом написание кода, призванного воплотить в жизнь идеи разработчика. В прошлом, когда я только начинал работать над новыми проектами и, погружаясь в них с головой, забывал обо всём на свете, мне следовало бы помнить то, о чём говорил мне один мудрый преподаватель:
«Делай коммиты раньше, делай коммиты чаще. Написал две строчки кода — сделай коммит».
Коммит — это фиксация или сохранение изменений в файле, проекте, репозитории. Когда я сделал свой первый настоящий коммит, выглядел он примерно так:
Если вам не знаком Git, мы сейчас это быстренько исправим. В первой строчке добавляем код со всеми внесёнными изменениями в область индексирования Git. Во второй строчке коммитим/сохраняем этот проиндексированный код в локальном гит репозитории. Наконец, в третьей строке отправляем изменения в репозиторий. Что ж, так делать коммиты тоже можно, особенно новичкам, неискушённым в тонкостях гит процесса. Но при работе над более сложными проектами в будущем могут возникнуть затруднения.
Об этом мне поведал один опытный разработчик, от которого я узнал о более продвинутом способе делать гит коммиты, а именно git add -p . Узнаем, почему надо делать коммиты маленькими, какая команда поможет делать их более адресными, детализированными и эффектными, а также выработать привычку делать коммиты чаще.
Почему важно делать коммиты маленькими?
Так уж повелось у разработчиков делать маленькие, легкочитаемые коммиты, и для этого есть причины. Во-первых, чем меньше коммит, тем легче отследить изменения. Во-вторых, такие коммиты позволяют быстро вносить исправления, если вы случайно что-то накосячили с приложением. Ну и в маленьком коммите любой желающий понять, для чего вы делали тот или иной апдейт или добавляли новую опцию, без труда найдёт ответ на свой вопрос.
Что такое git add -patch?
git add -p (сокращенно от git add --patch ) — это гит опция для создания более конкретных, детализированных коммитов. Она пробегает по всем новым изменениям в коде и выводит сразу большие куски с изменениями. Вам лишь остаётся решить, что из этого индексировать, а что нет.
Закончив с изменениями, просто введите команду:
В выделенном жирным шрифтом тексте видим файл, в который внесены изменения после предыдущего коммита. Зелёным цветом обозначено то, что было добавлено в файл. Вот как будет выглядеть код, если мы сейчас внесём в него изменения:
То, что было зелёным, стало красным, а зелёным цветом обозначены теперь только что внесённые изменения. Последняя строка содержит вопрос (что делать с этим куском кода?) и варианты ответа на него. Давайте разберём, что означает каждый вариант.
Краткое описание каждого варианта доступно после ввода знака “?” И нажатия на enter. Вот такой текст появится у вас в терминале:
А это более подробное описание:
Самые полезные, по моему мнению, команды: y, n, s и ?. Но использовал я их не одновременно. Переходя от одного куска кода к другому, надо решать, индексировать его или нет, пока не будут пройдены все внесённые изменения или не произойдёт выход из процесса.
По завершении процесса индексирования можно создать гораздо более чёткий коммит:
Для чего это нужно?
Есть несколько причин начать использовать эту технику индексирования при написании коммитов уже сегодня!
Первая: если вы тоже уйдёте с головой в программирование, позабыв обо всём на свете, в том числе и про коммиты, использование этой техники поможет вам проанализировать код, разобрать любые внесённые изменения и решить, что коммитить нужно и что коммитить не нужно в каждом конкретном коммите.
Вторая: этот процесс индексирования даёт возможность ещё раз пробежаться по сделанным изменениям, перед тем как их закоммитить.
Третья (от себя лично): с тех пор как я её использую, у меня сформировалась привычка делать маленькие коммиты.
Заключение
git add -p — это отличная техника, которая помогает делать маленькие, зато более конкретные и детализированные коммиты, прекрасно дополняя любой рабочий процесс на гит.
Читайте также: