Добавили файлы в индекс затем изменили их и выполнили команду git commit
Обновлено: 07.07.2024
Команда git add
Команда commit отправляет файлы в локальный репозиторий.
Дело в том, что в параметрах commit не указывается, какие файлы включать в снимок. Это делается заранее в команде add, а в команде commit пишется просто комментарий и в репозиторий отправляются все подготовленные файлы из индекса (staging area).
Можно добавлять в индекс как файлы, так и папки. Например, эта команда подготовит для будущего снимка папку <имя_папки1> и файл <имя_файла1>:
При этом все остальные файлы, даже если они отслеживаются в репозитории (tracked files) и были отредактированы (edited files), в следующий снимок не попадут.
Есть удобные вариации команды add:
Нетрудно заметить, что команда:
эквивалентна двум поочередно выполненным командам:
Удаление файлов из репозитория и с диска
Если речь идет об отдельном файле, то команда:
добавляет файл <имя_файла> в индекс как удаленный. При этом файл удаляется и с диска, если еще не был удален оттуда.
Удаление файлов только из репозитория
Бывает надо удалить файлы из репозитория, но не удалять с диска. Например, мы отправили в репозиторий логи, которым там не место.
А на диске они должны оставаться. Чтобы добавить этот лог в индекс как удаленный, но оставить его при этом на диске, выполним команду:
То же самое для папки делается так:
Что войдет в следующий снимок
Чтобы посмотреть, что же вы итоге подготовили для снимка, выполните команду:
Команда git commit
add и commit одной строкой
Бывает удобным отправлять файлы в репозиторий побыстрее, не выполняя по очереди add и commit. Можно выполнить эти команды и вместе:
Обратите внимание, что удаленные файлы затронуты не будут.
Но можно создать в конфигурации любую команду из комбинации add и commit (правда, это редко используется):
Мы создали команду add-commit. И с помощью нее можем выполнять действия:
Как отменить последний commit
Чтобы отменить последний локальный commit, выполните команду:
1 указывает на предыдущую ревизию, так что команда вернет репозиторий к предыдущему состоянию.
Как отменить git add
Чтобы удалить все файлы из staging area, выполните команду:
Чтобы удалить конкретный файл, выполните команду:
Как удалить некоторые файлы из снимка
Специальной команды тут нет. Для этого надо отменить последнюю команду commit. Эта команда сдвигает указатель на предыдущее состояние:
В индексе останутся файлы. Надо удалить из индекса нежелательный файл:
Подробнее о команде reset читайте здесь.
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.
Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний снимок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что Git только что их извлек и вы ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.
Определение состояния файлов
Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status . Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
Это означает, что у вас чистый рабочий каталог, другими словами — в нем нет отслеживаемых измененных файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. Наконец, команда сообщает вам на какой ветке вы находитесь и сообщает вам, что она не расходится с веткой на сервере. Пока что это всегда ветка master , ветка по умолчанию; в этой главе это не важно. В главе Ветвление в Git будут рассмотрены ветки и ссылки более детально.
Предположим, вы добавили в свой проект новый файл, простой файл README . Если этого файла раньше не было, и вы выполните git status , вы увидите свой неотслеживаемый файл вот так:
Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции «Untracked files» в выводе команды status . Статус Untracked означает, что Git видит файл, которого не было в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. Мы хотели добавить README, так давайте сделаем это.
Отслеживание новых файлов
Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add . Чтобы начать отслеживание файла README , вы можете выполнить следующее:
Если вы снова выполните команду status , то увидите, что файл README теперь отслеживаемый и добавлен в индекс:
Вы можете видеть, что файл проиндексирован, так как он находится в секции «Changes to be committed». Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add , будет добавлена в историю снимков состояния. Как вы помните, когда вы ранее выполнили git init , затем вы выполнили git add (файлы) — это было сделано для того, чтобы добавить файлы в вашем каталоге под версионный контроль. Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет все файлы из указанного каталога в индекс.
Индексация изменённых файлов
Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл CONTRIBUTING.md и после этого снова выполните команду git status , то результат будет примерно следующим:
Файл CONTRIBUTING.md находится в секции «Changes not staged for commit» — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду git add . Это многофункциональная команда, она используется для добавления под версионный контроль новых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния. Вам может быть понятнее, если вы будете думать об этом как «добавить этот контент в следующий коммит», а не как «добавить этот файл в проект». Выполним git add , чтобы проиндексировать CONTRIBUTING.md , а затем снова выполним git status :
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Что за чёрт? Теперь CONTRIBUTING.md отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add . Если вы выполните коммит сейчас, то файл CONTRIBUTING.md попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit . Если вы изменили файл после выполнения git add , вам придётся снова выполнить git add , чтобы проиндексировать последнюю версию файла:
Сокращенный вывод статуса
Вывод команды git status довольно всеобъемлющий и многословный. Git также имеет флаг вывода сокращенного статуса, так что вы можете увидеть изменения в более компактном виде. Если вы выполните git status -s или git status --short вы получите гораздо более упрощенный вывод:
Новые неотслеживаемые файлы помечены ?? слева от них, файлы добавленные в отслеживаемые помечены A , отредактированные файлы помечены M и так далее. В выводе содержится два столбца — в левом указывается статус файла, а в правом модифицирован ли он после этого. К примеру в нашем выводе, файл README модифицирован в рабочем каталоге, но не проиндексирован, а файл lib/simplegit.rb модифицирован и проиндексирован. Файл Rakefile модифицирован, проиндексирован и ещё раз модифицирован, таким образом на данный момент у него есть те изменения, которые попадут в коммит, и те, которые не попадут.
Игнорирование файлов
Зачастую, у вас имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых. К таким файлам обычно относятся автоматически генерируемые файлы (различные логи, результаты сборки программ и т. п.). В таком случае, вы можете создать файл .gitignore . с перечислением шаблонов соответствующих таким файлам. Вот пример файла .gitignore :
Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (
), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов. Вы можете также включить каталоги log, tmp или pid; автоматически создаваемую документацию; и т. д. и т. п. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.
К шаблонам в файле .gitignore применяются следующие правила:
Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.
Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.
Чтобы исключить каталог добавьте слеш (/) в конец шаблона.
Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
Glob-шаблоны представляют собой упрощённые регулярные выражения, используемые командными интерпретаторами. Символ ( * ) соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса ( ? ) соответствует одному символу; и квадратные скобки, в которые заключены символы, разделённые дефисом ( 2 ), соответствуют любому символу из интервала (в данном случае от 0 до 9). Вы также можете использовать две звёздочки, чтобы указать на вложенные каталоги: a/**/z соответствует a/z , a/b/z , a/b/c/z , и так далее.
Вот ещё один пример файла .gitignore :
В простейшем случае репозиторий будет иметь один файл .gitignore в корневом каталоге, правила из которого будут рекурсивно применяться ко всем подкаталогам. Так же возможно использовать .gitignore файлы в подкаталогах. Правила из этих файлов будут применяться только к каталогам, в которых они находятся. Например, репозиторий исходного кода ядра Linux содержит 206 файлов .gitignore .
Детальное рассмотрение использования нескольких .gitignore файлов выходит за пределы этой книги; детали доступны в справке man gitignore .
Просмотр индексированных и неиндексированных изменений
Допустим, вы снова изменили и проиндексировали файл README , а затем изменили файл CONTRIBUTING.md без индексирования. Если вы выполните команду git status , вы опять увидите что-то вроде:
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Если вы хотите посмотреть, что вы проиндексировали и что войдёт в следующий коммит, вы можете выполнить git diff --staged . Эта команда сравнивает ваши проиндексированные изменения с последним коммитом:
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:
Используйте git diff для просмотра непроиндексированных изменений
а так же git diff --cached для просмотра проиндексированных изменений ( --staged и --cached синонимы):
Мы будем продолжать использовать команду git diff различными способами на протяжении всей книги. Существует еще один способ просматривать эти изменения, если вы предпочитаете графический просмотр или внешнюю программу просмотра различий, вместо консоли. Выполнив команду git difftool вместо git diff , вы сможете просмотреть изменения в файле с помощью таких программ как emerge, vimdiff и других (включая коммерческие продукты). Выполните git difftool --tool-help чтобы увидеть какие из них уже установлены в вашей системе.
Коммит изменений
Теперь, когда ваш индекс находится в таком состоянии, как вам и хотелось, вы можете зафиксировать свои изменения. Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status , вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit :
Эта команда откроет выбранный вами текстовый редактор.
Редактор устанавливается переменной окружения EDITOR — обычно это vim или emacs, хотя вы можете установить любой другой с помощью команды git config --global core.editor , как было показано в главе Введение).
В редакторе будет отображён следующий текст (это пример окна Vim):
Для ещё более подробного напоминания, что же именно вы поменяли, можете передать аргумент -v в команду git commit . Это приведёт к тому, что в комментарий будет также помещена дельта/diff изменений, таким образом вы сможете точно увидеть все изменения которые вы совершили.
Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit указав его после параметра -m , как в следующем примере:
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и висит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add :
Обратите внимание, что в данном случае перед коммитом вам не нужно выполнять git add для файла CONTRIBUTING.md , потому что флаг -a включает все файлы. Это удобно, но будьте осторожны: флаг -a может включить в коммит нежелательные изменения.
Удаление файлов
Для того чтобы удалить файл из Git, вам необходимо удалить его из отслеживаемых файлов (точнее, удалить его из вашего индекса) а затем выполнить коммит. Это позволяет сделать команда git rm , которая также удаляет файл из вашего рабочего каталога, так что в следующий раз вы не увидите его как «неотслеживаемый».
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :
Затем, если вы выполните команду git rm , удаление файла попадёт в индекс:
После следующего коммита файл исчезнет и больше не будет отслеживаться. Если вы изменили файл и уже проиндексировали его, вы должны использовать принудительное удаление с помощью параметра -f . Это сделано для повышения безопасности, чтобы предотвратить ошибочное удаление данных, которые ещё не были записаны в снимок состояния и которые нельзя восстановить из Git.
Другая полезная штука, которую вы можете захотеть сделать — это удалить файл из индекса, оставив его при этом в рабочем каталоге. Другими словами, вы можете захотеть оставить файл на жёстком диске, но перестать отслеживать изменения в нём. Это особенно полезно, если вы забыли добавить что-то в файл .gitignore и по ошибке проиндексировали, например, большой файл с логами, или кучу промежуточных файлов компиляции. Чтобы сделать это, используйте опцию --cached :
В команду git rm можно передавать файлы, каталоги или шаблоны. Это означает, что вы можете сделать что-то вроде:
Обратите внимание на обратный слеш ( \ ) перед * . Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. Эта команда удаляет все файлы, имеющие расширение .log и находящиеся в каталоге log/ . Или же вы можете сделать вот так:
Эта команда удаляет все файлы, имена которых заканчиваются на
Перемещение файлов
В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.
Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Git неявно определяет, что произошло переименование, поэтому неважно, переименуете вы файл так или используя команду mv . Единственное отличие состоит лишь в том, что mv — одна команда вместо трёх — это функция для удобства. Важнее другое — вы можете использовать любой удобный способ для переименования файла, а затем воспользоваться командами add/rm перед коммитом.
Индекс в Git — это специальная промежуточная область, в которой хранятся изменения файлов на пути от рабочей директории до репозитория. При выполнении коммита в него попадают только те изменения, которые были добавлены в индекс.
Понятие индекса в Git появилось не случайно. Даже когда разработчик работает над одной задачей, по пути он натыкается на разные места в коде, которые либо плохо оформлены, либо содержат ошибки, либо должны быть исправлены в соответствии с какими-то новыми требованиями. И в большинстве ситуаций совершенно нормально исправлять эти недочеты, что все и делают. В итоге в рабочей директории появляется множество разных исправлений, которые частично относятся к выполняемой задаче, а частично содержат множественные исправления, напрямую не связанные с основными изменениями. В чём здесь проблема?
Если делать ровно один коммит, включающий в себя и основную задачу, и дополнительные исправления, то появляется несколько неприятных побочных эффектов. Во-первых, сложнее смотреть историю. Коммит начинает содержать совершенно несвязанные изменения, которые отвлекают во время ревью (проверки чужого кода).
Во-вторых, что вероятно даже важнее, откат коммита по любым причинам приведет к тому, что откатятся правки, которые всё равно нужно будет делать.
Именно здесь помогает индекс. Его наличие позволяет меньше переживать на тему того, как сформируется коммит.
Стандартный способ работы с индексом — это добавление или изменение файлов и последующий коммит:
Если речь идет про один-два файла, которые нужно закоммитить прямо сейчас, то можно сделать проще. Команда git commit принимает на вход аргументы — пути до файлов. Она автоматически добавляет эти файлы в индекс и затем в коммит. Данный подход работает только с уже отслеживаемыми файлами.
Иногда бывает наоборот — мы исправили много файлов и хотим добавить их в коммит сразу все. Тогда поможет точка:
Команда выше очень опасна. С ее помощью крайне легко закоммитить много лишнего, особенно если не помнить про необходимость перед коммитом смотреть git diff --staged .
Ну и совсем страшная, но полезная команда — это коммит с одновременным добавлением всего в индекс:
С другой стороны, нередко разные изменения делаются в одних и тех же файлах. То есть изменения в этих файлах по-хорошему должны находиться в разных коммитах. И даже такое можно сделать с помощью Git. Для этого подходит команда git add -i , которая показывает измененные куски файлов и спрашивает, что с ними сделать. С помощью этой команды можно очень точно выбрать то, что должно попасть в коммит, а что нет. Ее использование обычно показывает хороший уровень владения Git.
Самостоятельная работа
Попрактикуйтесь в использовании команд из урока, меняя содержимое репозитория
В Git и других системах управления версиями концепция сохранения проработана более детально, чем в текстовых процессорах или других традиционных приложениях для редактирования файлов. Традиционный термин «сохранение» в программировании синонимичен понятию коммита в Git. Коммит в Git является эквивалентом сохранения. Традиционное сохранение — это операция файловой системы, которая используется для перезаписи существующего файла или записи нового. В отличие от нее, коммит Git выполняется над набором файлов и каталогов.
Процессы сохранения в Git и SVN также отличаются. Коммиты, или «фиксации», в SVN — это операции передачи на централизованный удаленный сервер. Это означает, что для «сохранения» изменений в проекте коммитам SVN необходим доступ в Интернет. Коммиты Git можно создавать и выполнять локально, а затем по мере необходимости отправлять на удаленный сервер с помощью команды git push -u origin main . Различие этих двух методов объясняется фундаментальными отличиями в архитектуре. В Git реализована модель распределенного приложения, а в SVN — модель централизованного приложения. Обычно распределенные приложения более устойчивы, поскольку не имеют единой точки отказа, такой как централизованный сервер.
В Git имеется дополнительный механизм сохранения, который называется «stash». Stash — это временная область для хранения изменений, не готовых к коммиту. Команда stash работает с рабочим каталогом (первым из трех деревьев) и имеет множество вариантов применения. Подробнее см. на странице команды git stash .
Репозиторий Git можно настроить на игнорирование определенных файлов или каталогов. В этом случае Git не будет сохранять изменения в игнорируемом контенте. В Git имеется несколько способов настройки для управления списком игнорирования. Более подробно настройка игнорирования в Git рассматривается на странице git ignore .
git add
Команда git add добавляет изменение из рабочего каталога в раздел проиндексированных файлов. Она сообщает Git, что вы хотите включить изменения в конкретном файле в следующий коммит. Однако на самом деле команда git add не оказывает существенного влияния на репозиторий: изменения регистрируются в нем только после выполнения команды git commit .
Наряду с этими командами вам понадобится команда git status , которая показывает состояние рабочего каталога и раздела проиндексированных файлов.
Порядок действий
Команды git add и git commit составляют основу рабочего процесса Git. Эти две команды должен изучить и понимать каждый пользователь Git, независимо от модели совместной работы, принятой в его команде. Эти команды используются для записи версий проекта в историю репозитория.
Работа над проектом ведется по стандартной схеме «редактирование — индексирование — коммит». Сначала вы редактируете файлы в рабочем каталоге. Когда вы будете готовы сохранить копию текущего состояния проекта, вы индексируете изменения командой git add . Затем вы вызываете команду git commit , которая добавляет проиндексированный снимок состояния в историю проекта. Для отмены коммита или проиндексированного снимка состояния используется команда git reset .
Для полноценного процесса совместной работы в Git помимо git add и git commit необходима третья команда — git push . git push используется для отправки подтвержденных изменений в удаленные репозитории для совместной работы, чтобы к набору сохраненных изменений могли получить доступ другие участники команды.
Команду git add не следует путать с командой svn add , которая добавляет файл в репозиторий. git add работает на более абстрактном уровне изменений. Это означает, что команду git add необходимо вызывать при каждом изменении файла, тогда как svn add вызывается для каждого файла только один раз. Это может показаться избыточным, но такой рабочий процесс облегчает поддержание порядка в проекте.
Раздел проиндексированных файлов
Основное назначение команды git add состоит в переносе ожидающих изменений из рабочего каталога в раздел проиндексированных файлов Git . Раздел проиндексированных файлов — это уникальная возможность Git, и если вы прежде работали с SVN (или даже с Mercurial), вам потребуется некоторое время, чтобы освоить ее. Этот раздел удобно рассматривать как буфер между рабочим каталогом и историей проекта. Раздел проиндексированных файлов является одним из «трех деревьев» Git, наряду с рабочим каталогом и историей коммитов.
Вместо того чтобы подтверждать все изменения, внесенные после последнего коммита, вы можете сгруппировать связанные изменения в определенные снимки состояний в разделе проиндексированных файлов, прежде чем выполнять их коммит в историю проекта. Это означает, что вы можете внести различные изменения в несвязанные файлы, а затем вернуться назад и разбить их на логические коммиты (добавляя в раздел проиндексированных файлов связанные изменения и поэтапно выполняя коммиты для отдельных групп изменений). В Git, как и в любой системе контроля версий, важно создавать мелкие коммиты, чтобы можно было легко отслеживать ошибки и отменять изменения с минимальным влиянием на остальной проект.
Распространенные опции
Проиндексировать все изменения в файле file> для следующего коммита.
Проиндексировать все изменения в каталоге directory> для следующего коммита.
Начать интерактивный сеанс индексирования, во время которого вы сможете выбрать части файла, которые будут добавлены в следующий коммит. Команда представит фрагмент изменений и предложит вам ввести команду. Введите y , чтобы проиндексировать фрагмент; n , чтобы игнорировать фрагмент; s , чтобы разбить его на более мелкие фрагменты; e , чтобы вручную отредактировать фрагмент; q , чтобы завершить работу с командой.
Примеры
Когда вы только начинаете новый проект, команда git add выполняет ту же функцию, что и svn import . Чтобы создать первичный коммит текущего каталога, используйте следующие две команды:
После того как начнется работа над проектом, можно будет добавить новые файлы, указав путь в команде git add :
Приведенную выше команду можно также использовать для регистрации изменений в существующих файлах. Вспомним, что Git не различает индексацию изменений в новых файлах и в файлах, которые уже добавлены в репозиторий.
Резюме
Подведем итоги. Команда git add — это первая команда в цепочке операций, предписывающей Git «сохранить» снимок текущего состояния проекта в истории коммитов. Когда git add используется как отдельная команда, она переносит ожидающие изменения из рабочего каталога в раздел проиндексированных файлов. Команда git status проверяет текущее состояние репозитория; с ее помощью можно убедиться, что команда git add добавила нужные изменения. Команда git reset используется для отмены команды git add . Команда git commit сохраняет снимок состояния из раздела проиндексированных файлов в истории коммитов репозитория.
Начал разбираться в системе контроле версий Git и понял что не могу понять, что означает термин индексация. Приведу пример :
Изменения файла hello.html были проиндексированы. Это означает, что git теперь знает об изменении, но изменение пока не перманентно (читай, навсегда) записано в репозиторий. Следующий коммит будет включать в себя проиндексированные изменения.Если вы решили, что не хотите коммитить изменения, команда состояния напомнит вам о том, что с помощью команды git reset можно снять индексацию этих изменений.
Так вот вопрос, как здесь понимать индексацию?
что такое индексирование?
индексирование (также: indexing, staging) — это процесс добавления текущего содержимого (изменённого) файла в индекс (также: index area, staging area).
какой командой выполняется это добавление?
что при этом происходит с технической точки зрения?
берётся содержимое файла, впереди к нему дописывается немного служебной информации, высчитывается sha1sum от получившегося (это т.н. хэш), затем всё это сжимается и сохраняется в файле в каталоге .git/objects . имя файла уникально, т.к. формируется на основании полученного хэша.
затем в файл .git/index дописывается ещё одна запись о добавленном файле (сохраняется имя файла, а также тот самый хэш, и ещё некоторое количество служебной информации):
и что, этот файл .git/index всё растёт и растёт? он же станет со временем гигантского размера!
записи в этом файле заново пересоздаются в результате переключения содержимого рабочего каталога командой checkout . кстати, именно из этого файла программа git черпает информацию о том, какие именно изменения должны быть зафиксированы с помощью commit-а (используется содержимое этого файла и при некоторых других операциях — см. подробнее в документации). среди других команд, добавляющих либо удаляющих записи в этом файле, стоит отметить reset , rm , stash .
так для чего он вообще нужен, этот «индекс»?
с технической точки зрения основная цель его существования — избежать (ресурсоёмких) операций с файлами в рабочем каталоге (working tree) при выполнении команды commit . благодаря его наличию при выполнении команды commit не производится никаких манипуляций с файлами в рабочем каталоге — ни поиск изменённых файлов, ни сжатие их текущего содержимого. (оговорка: при наличии опций -a/--all/-p/--patch/--interactive команды commit все эти оптимизации «идут коту под хвост»: выполняется и поиск и сжатие).
Читайте также: