Как индексировать файлы и фиксировать с помощью одной команды

Обновлено: 03.07.2024

Получите полный доступ к Git Pocket Guide и более чем 60 000 других наименований с бесплатной 10-дневной пробной версией O'Reilly.

Есть также прямые онлайн-мероприятия, интерактивный контент, материалы для подготовки к сертификации и многое другое.

Глава 3. Создание коммитов

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

Изменение индекса

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

git-коммит

Предоставление git commit определенного имени файла работает по-другому: он игнорирует индекс и фиксирует только изменения в этом файле.

Добавление нового файла

Это подходящая мнемоника, но обратите внимание на следующую команду.

Добавление изменений в существующий файл

Да, это та же самая команда. В обоих случаях Git добавляет текущее содержимое рабочего файла в базу данных объектов как новый объект типа blob (при условии, что его еще нет) и отмечает изменение в индексе. Если файл новый, то это будет новая запись индекса; если нет, просто обновленный, указывающий на новый объект (или с измененными атрибутами, такими как разрешения), но по сути это та же операция для Git. Файл считается «новым», если его путь не указан в индексе, что обычно означает, что он не был частью последней фиксации; это то, что заставляет git status помечать файл как «неотслеживаемый» до того, как вы его добавите (файлы в индексе называются «отслеживаемыми», и Git, вообще говоря, заботится о них).

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

Добавление частичных изменений

Вы также можете добавить только некоторые изменения, которые вы сделали в файл, используя git add --patch (-p) . Это запускает интерактивный цикл, в котором вы можете выбрать части внесенных вами изменений и пропустить другие. Когда вы закончите, Git добавит в индекс версии соответствующих файлов только с примененными к ним изменениями. git status сообщает об этой ситуации, указывая один и тот же файл как под «изменениями, не подготовленными для фиксации» , так и под «изменениями, которые необходимо зафиксировать», поскольку теперь файл содержит оба этих параметра.

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

Интерактивный цикл имеет ряд опций со встроенной справкой (используйте «?»), но обратите особое внимание на команду s для разделения набора изменений, называемого «фрагментом», на более мелкие изменения (если первоначальный анализ Git склеивает вместе). фрагменты, которые вы хотите разделить), и команду e, которая позволяет вам редактировать ханки самостоятельно. Если вы установите переменную конфигурации интерактивного.singlekey Git, вы можете использовать одно нажатие клавиши для этих команд и пропустить ввод return после каждой.

Просто запустив git add -p без аргументов, вы сможете просмотреть все файлы с неустановленными изменениями (в отличие от простого git add , для которого требуется аргумент или параметр, чтобы указать, что нужно добавить). Вы также можете указать определенные файлы для рассмотрения в качестве аргументов.

git add -p на самом деле является частным случаем git add --interactive (-i) . Последний начинается на более высоком уровне, позволяя вам просматривать статус, добавлять неотслеживаемые файлы, возвращаться к версии HEAD, выбирать файлы для исправления и т. д.; git add -p просто переходит прямо к подкоманде patch команды git add -i .

Ярлыки

git add -u Включить все файлы в текущий индекс; сюда входят измененные и удаленные файлы, но не новые. git add -A Включить все имена файлов в индекс и в рабочее дерево; это также создает новые файлы. Это полезно, если вы импортируете новую версию кода из другого источника, не входящего в Git, традиционно называемого «ветвью поставщика». Вы должны заменить свое рабочее дерево распакованным новым кодом, а затем использовать git add -A для подготовки всех изменений, дополнений и удалений, необходимых для фиксации новой версии. Добавьте -f, чтобы включить обычно игнорируемые файлы.

Удаление файла

Это делает две вещи:

Удаляет запись файла из индекса, планируя ее удаление при следующей фиксации.
Также удаляет рабочий файл, как и при использовании rm filename

Если вам случится сначала удалить рабочий файл самостоятельно, это не проблема; Гиту все равно. Удаление его из индекса имеет значение; удаление рабочей копии после этого просто аккуратно.В обоих случаях статус git покажет файл как удаленный; разница будет заключаться в том, указаны ли они в разделе «изменения, не подготовленные для фиксации» (если вы только что удалили рабочий файл) или «изменения, которые необходимо зафиксировать» (если вы использовали git rm ).

Однако git rm для файла, еще не находящегося под контролем версий, работать не будет; просто используйте rm .

Переименование файла

Переименовать файл или переместить каталог в Git очень просто с помощью команды git mv:

На самом деле это просто быстрый способ переименовать рабочий файл вне Git, а затем использовать git add для нового имени:

Переименование — сложная тема в управлении версиями. Переименование файла в некотором смысле эквивалентно удалению этого файла и созданию нового с другим именем и тем же содержимым, но это также может произойти без вашего намерения что-либо переименовывать, если новый файл просто совпадает со старым. . Это различие связано с намерением, и поэтому оно должно быть представлено системой отдельно, если оно вообще должно быть зафиксировано. И это может быть очень важно сделать, потому что люди обычно хотят, чтобы история переименованного файла была сохранена; даже называя то, что мы сделали, «переименованием», мы неявно говорим, что это действительно «тот же самый файл, только с другим именем». Мы не хотим потерять историю только потому, что сменили название. Напрашивается вопрос: что же такое «файл»? Это только содержание? Нет, потому что мы отслеживаем изменения содержимого одного и того же файла с течением времени. Это просто имя? Нет, потому что иногда мы хотим «переименовать» файл, который считает содержимое первичным, а имя вторичным. Правда в том, что на этот вопрос нет однозначного ответа, поскольку он зависит от пожеланий пользователя в конкретной ситуации, и поэтому сложно разработать единую систему, подходящую для него, и системы различаются по тому, как они это делают. CVS вообще не поддерживает переименование. Subversion имеет явное переименование: оно представляет собой операцию переименования отдельно от пары удаления/создания. Это имеет некоторые преимущества, но также значительно усложняет систему для его поддержки.

Подход Git заключается в том, чтобы не отслеживать переименование явно, а делать выводы о нем на основе комбинаций изменений имени и содержимого; адресация на основе содержимого делает это особенно простым и привлекательным с точки зрения реализации. Git вообще не имеет внутренней функции «переименования»; как указано, git mv — это просто ярлык. Если вы запустите git status после первой команды ранее, вы увидите то, что и ожидали: Git показывает foo как удаленный, а новый файл bar — как неотслеживаемый. Если вы сделаете это после git add , вы увидите только одну аннотацию: named: foo -> bar . Git видит, что файл для определенной записи индекса был удален с диска, а новая запись появилась с другим именем файла, но тот же идентификатор объекта и, следовательно, с тем же содержимым. Он также может рассматривать переименование относительно менее строгого понятия эквивалентности файлов, то есть, если новый файл достаточно похож на тот, который был удален, а не идентичен на 100% (см. параметры переименования и обнаружения копирования в главе 9).< /p>

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

Неустановленные изменения

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

Вы также можете указать определенные файлы или каталоги для сброса, оставив поэтапные изменения в других файлах. С помощью git reset --patch вы можете быть еще более конкретным, интерактивно выбирая части ваших поэтапных изменений для удаления; это обратная сторона git add -p . Другие варианты см. в разделе Отмена любого количества коммитов.

Совершение фиксации

Подготовив нужный индекс, используйте git commit, чтобы сохранить его как новую фиксацию. Сначала используйте git status, чтобы проверить задействованные файлы, и git diff --cached, чтобы проверить фактические изменения, которые вы применяете. Только git diff показывает все оставшиеся неустановленные изменения (разница между вашим рабочим деревом и индексом); добавление --cached (или синоним --staged ) вместо этого показывает разницу между индексом и последней фиксацией (т. е. изменения, которые вы собираетесь внести с этой фиксацией).

Зафиксировать сообщения

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

Если вы этого не сделаете, Git запустит текстовый редактор, чтобы вы могли ввести свое сообщение; Текстовый редактор описывает, как выбирается редактор. Хотя текст имеет произвольную форму, обычная практика состоит в том, чтобы длина первой строки не превышала 50–60 символов или около того. Если вам нужны дополнительные строки, отделите их от первой пустой строкой, а оставшиеся абзацы оберните до 72 символов. Первая строка должна служить в качестве темы для коммита, как и в электронном письме. Цель состоит в том, чтобы позволить спискам, включающим сообщение фиксации, сокращать сообщение первой строкой, оставляя место для некоторой другой информации в строке (например, git log --oneline ).

На самом деле очень важно следовать этому соглашению, поскольку многие программы, связанные с Git, а также различные части самого Git предполагают его. Строка темы фиксации адресуется как отдельный объект при написании форматов фиксации и извлечении информации о фиксации, а программы, которые отображают фиксации в различных контекстах, предполагают, что тема будет иметь смысл сама по себе и не будет слишком длинной. GitHub и gitweb делают это визуально, например, отображая тему как отдельный элемент жирным шрифтом вверху, а остальную часть сообщения («тело»), если таковая имеется, выделена более мелким шрифтом. текст ниже. Вы получите странные результаты, которые трудно прочитать, если первая строка представляет собой просто фрагмент предложения и/или слишком длинна, чтобы поместиться на отведенном месте.

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

Что делает коммит хорошим?

Это зависит от того, как вы собираетесь использовать свой репозиторий и Git в целом; на этот вопрос нет единственно правильного ответа. Некоторые люди используют соглашение (если контент представляет собой программное обеспечение), согласно которому каждый коммит должен быть компилируемым, а это означает, что коммиты, как правило, будут больше, поскольку они должны содержать все, что требуется для продвижения кода от одного последовательного этапа к другому. Другой подход состоит в том, чтобы структурировать ваши коммиты в первую очередь так, чтобы использовать возможности Git для их передачи и повторного использования. При подготовке коммита спросите себя: содержит ли он полностью и только те изменения, которые необходимы для выполнения того, о чем говорится в сообщении коммита? Если в коммите говорится, что он реализует функцию, есть ли у кого-то, кто использует git cherry-pick, чтобы опробовать эту функцию, приличные шансы на успех, или коммит также содержит несвязанные изменения, которые усложнят это? Подумайте также о том, чтобы позже использовать git revert для отмены изменений или о слиянии этой ветки с другими ветками для включения новой функции. В этом стиле каждая фиксация может не создавать функциональное программное обеспечение, поскольку имеет смысл представлять большое общее изменение в виде серии коммитов, чтобы лучше повторно использовать его части. Вы можете использовать другие методы для указания более крупных контрольных точек проекта, таких как сборочные промежуточные версии, включая теги Git или уникальные строки в сообщениях коммитов, которые вы можете найти с помощью git log --grep .

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

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

Ярлыки

git commit -a добавляет все отслеживаемые измененные файлы в индекс перед фиксацией. При этом фиксируются измененные и удаленные файлы, но не новые; это эквивалентно git add -u, за которым следует git commit . Однако будьте осторожны; если вы слишком привыкнете к использованию этой команды, вы можете случайно зафиксировать некоторые изменения, которые вы не собирались делать, хотя это легко отменить; см. следующую главу.

Пустые каталоги

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

Рабочий процесс фиксации

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

Используйте git add (с различными параметрами), чтобы подготовить подмножество ваших изменений.
Запустите git stash --keep-index . Это сохраняет и отменяет незавершенные неустановленные изменения, сохраняя поэтапные изменения в индексе и сбрасывая рабочее дерево в соответствии с индексом.
Изучите это рабочее состояние дерева, чтобы убедиться, что выбранные вами изменения имеют смысл; Например, создайте и протестируйте свое программное обеспечение.
Запустите git commit .
Теперь используйте git stash pop, чтобы восстановить оставшиеся неустановленные изменения, и вернитесь к шагу 1. Продолжайте этот процесс до тех пор, пока вы не зафиксируете все свои изменения, что подтверждается отчетом о состоянии git «ничего для фиксации, рабочий каталог чист.

Подробнее о полезной команде git stash см. в разделе git stash.

Получите карманное руководство по Git прямо сейчас с онлайн-обучением O’Reilly.

Члены O’Reilly проходят онлайн-обучение в режиме реального времени, а также получают книги, видео и цифровой контент от более чем 200 издателей.

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

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

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

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

Команда git add по умолчанию не добавляет игнорируемые файлы. Если какие-либо игнорируемые файлы были явно указаны в командной строке, git add завершится ошибкой со списком игнорируемых файлов. Игнорируемые файлы, достигнутые рекурсией каталога или подстановкой имен файлов, выполненной Git (укажите ваши глобусы перед оболочкой), будут молча игнорироваться. Команду git add можно использовать для добавления игнорируемых файлов с параметром -f (force).

Пожалуйста, см. git-commit[1] для альтернативных способов добавления контента в фиксацию.

ВАРИАНТЫ

Файлы, из которых нужно добавить контент. Fileglobs (например, *.c ) могут быть заданы для добавления всех соответствующих файлов. Также можно указать начальное имя каталога (например, dir для добавления dir/file1 и dir/file2 ) для обновления индекса в соответствии с текущим состоянием каталога в целом (например, при указании dir будет записан не только измененный файл dir/file1 ). в рабочем дереве файл dir/file2 добавлен в рабочее дерево, а также файл dir/file3 удален из рабочего дерева). Обратите внимание, что старые версии Git игнорировали удаленные файлы; используйте параметр --no-all, если вы хотите добавить измененные или новые файлы, но игнорировать удаленные.

Подробнее о

синтаксис, см. запись pathspec в gitglossary[7].

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

Разрешить добавление игнорируемых файлов.

Разрешить обновление записей индекса за пределами конуса разреженной проверки. Обычно git add отказывается обновлять записи индекса, пути которых не соответствуют конусу разреженной проверки, поскольку эти файлы могут быть удалены из рабочего дерева без предупреждения. Дополнительные сведения см. в git-sparse-checkout[1].

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

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

Это эффективно запускает add --interactive , но пропускает начальное меню команд и сразу переходит к подкоманде patch. Подробнее см. в разделе «Интерактивный режим».

Откройте сравнение с индексом в редакторе и позвольте пользователю отредактировать его. После закрытия редактора откорректируйте заголовки фрагментов и примените патч к индексу.

Назначение этой опции состоит в том, чтобы выбрать строки патча для применения или даже изменить содержимое строк, которые нужно подготовить. Это может быть быстрее и гибче, чем использование интерактивного селектора фрагментов. Однако легко запутаться и создать патч, не относящийся к индексу. См. РЕДАКТИРОВАНИЕ ПАТЧЕЙ ниже.

Обновите индекс только там, где уже есть совпадающая запись

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

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

Обновлять индекс не только там, где в рабочем дереве есть соответствующий файл

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

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

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

Этот параметр предназначен в первую очередь для помощи пользователям, которые привыкли к более старым версиям Git, которым "git add

…» был синонимом «git add --no-all

…", т. е. игнорируются удаленные файлы.

Запишите только тот факт, что путь будет добавлен позже. Запись пути помещается в указатель без содержания. Это полезно, помимо прочего, для отображения неустановленного содержимого таких файлов с помощью git diff и их фиксации с помощью git commit -a .

Не добавляйте файл(ы), а только обновите их информацию stat() в индексе.

Если какие-то файлы не удалось добавить из-за ошибок их индексации, не прерывайте операцию, а продолжайте добавлять другие. Команда по-прежнему должна выходить с ненулевым статусом. Для переменной конфигурации add.ignoreErrors можно установить значение true, чтобы сделать это поведение по умолчанию.

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

По умолчанию git add выдает предупреждение при добавлении встроенного репозитория в индекс без использования git submodule add для создания записи в .gitmodules . Этот параметр отключит предупреждение (например, если вы вручную выполняете операции над подмодулями).

Свежепримените "очистку" ко всем отслеживаемым файлам, чтобы снова принудительно добавить их в индекс. Это полезно после изменения конфигурации core.autocrlf или текстового атрибута, чтобы исправить файлы, добавленные с неправильными окончаниями строк CRLF/LF. Эта опция подразумевает -u .

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

Pathspec передается вместо аргументов командной строки. Если точно - то используется стандартный ввод. Элементы Pathspec разделяются символами LF или CR/LF. Элементы Pathspec можно заключать в кавычки, как описано для переменной конфигурации core.quotePath (см. git-config[1]). См. также --pathspec-file-nul и global --literal-pathspecs .

Имеет смысл только с параметром --pathspec-from-file . Элементы Pathspec разделяются символом NUL, а все остальные символы воспринимаются буквально (включая символы новой строки и кавычки).

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

ПРИМЕРЫ

Добавляет содержимое из всех файлов *.txt в каталоге Documentation и его подкаталогах:

Обратите внимание, что в этом примере звездочка * взята из оболочки; это позволяет команде включать файлы из подкаталогов каталога Documentation/.

Рассматривает возможность добавления контента из всех скриптов git-*.sh:

Поскольку этот пример позволяет оболочке расширять звездочку (т. е. вы явно указываете файлы), он не учитывает subdir/git-foo.sh .

ИНТЕРАКТИВНЫЙ РЕЖИМ

Когда команда переходит в интерактивный режим, она показывает выходные данные подкоманды status, а затем переходит в интерактивный командный цикл.

Цикл команд показывает список доступных подкоманд и выдает подсказку "Что теперь>". Как правило, когда подсказка заканчивается одним >, вы можете выбрать только один из предложенных вариантов и ввести return, например:

Вы также можете сказать s, sta или status выше, если выбор уникален.

Основной цикл команд состоит из 6 подкоманд (плюс help и quit).

Это показывает разницу между HEAD и индексом (то есть, что будет зафиксировано, если вы скажете git commit ), а также между файлами индекса и рабочего дерева (то есть, что вы могли бы добавить перед git commit с помощью git add ) для каждого пути. Пример вывода выглядит следующим образом:

Это показывает, что файл foo.jpg отличается от файла HEAD (но это двоичный файл, поэтому количество строк не может быть показано), и нет никакой разницы между индексированной копией и версией рабочего дерева (если версия рабочего дерева также отличается, ничего было бы показано >binary).В другом файле, git-add--interactive.perl, добавлено 403 строки и удалено 35 строк, если вы фиксируете то, что находится в индексе, но рабочий файл дерева имеет дополнительные модификации (одно добавление и одно удаление).

При этом отображается информация о состоянии и выдается запрос "Обновить>>". Когда подсказка заканчивается двойным >>, вы можете сделать более одного выбора, объединенного пробелом или запятой. Также вы можете сказать диапазоны. Например. "2-5 7,9" для выбора 2,3,4,5,7,9 из списка. Если второе число в диапазоне опущено, берутся все оставшиеся патчи. Например. "7-" для выбора 7,8,9 из списка. Вы можете сказать *, чтобы выбрать все.

То, что вы выбрали, выделяется знаком *, например:

Чтобы снять выделение, поставьте перед входом префикс -, например:

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

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

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

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

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

Вы можете не вводить здесь return, установив для переменной конфигурацииinteractive.singleKey значение true .

Это позволяет просмотреть, что будет зафиксировано (например, между HEAD и index).

РЕДАКТИРОВАНИЕ ПАТЧЕЙ

Вызов команды git add -e или выбор e в интерактивном селекторе фрагментов откроет исправление в вашем редакторе; после выхода из редактора результат применяется к индексу. Вы можете вносить произвольные изменения в патч, но обратите внимание, что некоторые изменения могут привести к запутанным результатам или даже привести к тому, что патч будет неприменим. Если вы хотите полностью прервать операцию (т. е. ничего нового не добавлять в индекс), просто удалите все строки патча. В приведенном ниже списке описаны некоторые общие вещи, которые вы можете увидеть в патче, и какие операции редактирования имеют смысл для них.

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

Удаленный контент представлен строками, начинающимися с "-". Вы можете предотвратить их поэтапное удаление, заменив "-" на " " (пробел).

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

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

Избегайте использования этих конструкций или делайте это с особой осторожностью.

Содержимое, не отличающееся между индексом и рабочим деревом, может отображаться в строках контекста, начиная с " " (пробела). Вы можете настроить контекстные строки для удаления, преобразовав пробел в «-». В результате появится файл рабочего дерева с повторным добавлением содержимого.

изменение существующего контента

Можно также изменить строки контекста, подготовив их к удалению (преобразовав " " в "-") и добавив строку "+" с новым содержанием. Точно так же можно изменить строки «+» для существующих дополнений или модификаций. Во всех случаях новая модификация будет отображаться в рабочем дереве в обратном порядке.

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

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

Кажется, я часто использую эти две команды, и если бы в Git была такая опция, как git commit -Am "commit message" , это сделало бы жизнь намного удобнее.

git commit имеет модификатор -a, но это не совсем то же самое, что и git add -A перед фиксацией. git add -A добавляет вновь созданные файлы, а git commit -am - нет. Что делает?

лучше экономить время и фиксировать каждое изменение, поэтому я использую git commit -am "yes the code in commit"

git add -A и, что еще хуже, git add .оба вредны и не должны использоваться в подавляющем большинстве сценариев. Вы хотите, чтобы git add -p или git add -i действительно учитывал то, что вы создаете.

27 ответов 27

Вы можете использовать псевдонимы git, например,

и использовать его с

РЕДАКТИРОВАТЬ: Вернуться к галочкам ('), так как в противном случае расширение оболочки в Linux будет невозможным. В Windows вместо этого следует использовать двойные кавычки ("") (указано в комментариях, не проверял).

@MrFusion Делает команду внешней командой оболочки вместо ярлыка во внутренней команде git, т. е. вся строка выполняется как отдельный процесс.

Я предпочитаю git config --global alias.add-commit '!git add -A && git commit -m', чтобы мне не приходилось каждый раз вводить -m.

Мне лень каждый раз набирать "добавить-фиксацию" и "-m". Следовательно, я набираю: git config --global alias.ac '!git add -A && git commit -m' каждый раз, когда просто набираю: git ac 'comment' :)

git config --global alias.add-commit "!git add -A && git commit" (т.е. двойные кавычки вместо одинарных) работает в Windows.

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

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

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

или просто git commit -am "message" - просто убедитесь, что нет новых файлов, которые git еще не подхватил. в противном случае вам нужно будет использовать git add . && перед этим. сделать это в одну строку.

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

Эта строка добавит и зафиксирует все измененные и добавленные файлы в репозиторий.

Самое простое, что вы можете сделать, это:

Я не понимаю, почему мы все усложняем.

Привет, @tymtam, эта команда добавляет все отслеживаемые файлы в промежуточную область и фиксирует с заданным сообщением. Неотслеживаемые файлы добавляются в промежуточную область с помощью команды git add -A.

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

Только адаптация ответа Алеся и комментария суда для linux bash:

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

git commit -am "комментарий"

Эта строка добавит и зафиксирует все изменения в репозитории.

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

git добавить . ; git commit -am "сообщение"

git commit -am "comment" — это ярлык для добавления и фиксации всех измененных файлов. Если вы хотите добавить и зафиксировать только 1 файл, вам нужно будет выполнить: git add file.txt ; git commit -m "комментарий"

Просто объедините свои команды:

В более поздних версиях git вы можете добавлять и фиксировать вот так

Дополнительно вы псевдоним:

Тогда вы можете использовать его следующим образом:

На моем компьютере с Windows я установил этот псевдоним .bashrc, чтобы упростить весь процесс.

добавить следующую строку в файл

это git add commit и push . изменить его любым способом, скажем, вы не хотите, чтобы команда push удаляла эту часть

перезагрузите .bashrc / закройте и снова откройте оболочку

почти уверен, что вы можете использовать:

Эта команда является кратчайшим и, вероятно, самым простым способом достижения требуемого результата. Протестируйте на git версии 2.6.3.windows.1.

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

git добавить . сокращается до ga .
git commit -m "сообщение" сокращено до gc -m "сообщение"
git push сокращено до gp
git fetch сокращено до gf
главный источник git pull сокращен до ggl master
главный источник git push сокращен до ggp master
git checkout -b сокращено до gcb
git merge сокращено до gm
git remote сокращенно до gr
статус git сокращен до gst

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

Обратите внимание на "." в конце. который также может быть путем к файлу/каталогу

У меня есть эта функция в моем .bash_profile, или .profile, или .zprofile, или любом другом файле, полученном в оболочках входа:

один раз вам нужно будет просто ввести

Это должен быть лучший ответ, очень простой и включает НЕОТСЛЕЖИВАЕМЫЕ файлы, в отличие от большинства других предложений.

сохраните, например, git.sh и позже вызовите:

@naught101 очевидно, что git может сделать это самостоятельно, дело в том, что эта оболочка служит для упрощения процесса для людей, использующих git в Linux, так как гораздо проще запустить sh git.sh сообщение о коммите, а не быть сделанным переносимым не означает, что он будет работать должным образом.

Создайте псевдоним в bash: alias gac="git add -A && git commit -m"

(Я назвал ярлык "gac", но это не обязательно)

Используйте это: gac 'здесь ваше сообщение о коммите'

Я использую следующее (оба находятся в стадии разработки, поэтому я постараюсь не забыть обновить это):

Я получаю окно vim, чтобы получить больше инструментов для редактирования моего сообщения о коммите.

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

@Yunnosch Думаю, я не видел ответа Навида перед публикацией, так как он «слишком ленив»: P, чтобы публиковать его как полный ответ. Действительно, это то же самое, и вообще-то этот псевдоним у меня давно, позаимствовал у коллеги. Так что я думаю, мы можем назвать это: цепь плагиата. Извините, если это вас побеспокоило.

Сначала проверьте, какие у вас псевдонимы.

// git add commit -m

Например, если вы используете последний.

Нравится выбор. Вы даже можете добавить git config --global alias.acmp '!git add -A && git commit -m "update" && git push'

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

Я назвал его "gitfile.sh" и добавил в свой $PATH. Затем я могу запустить git add и зафиксировать один файл одной командой:

Для серебристых спин в толпе, привыкших к таким вещам, как Subversion. сделать «фиксацию» в старом смысле этого слова (т.е. — или, говоря языком git, — добавить, зафиксировать и отправить) за один шаг. Я обычно добавляю что-то вроде следующего в корень моего проекта (как bat-файл в Windows, например, git-commit.bat). Затем, когда я хочу добавить, зафиксировать и отправить, я просто набираю что-то вроде git-commit «Добавил кое-что новое», и все это отправляется в удаленное репо.

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

Обычно я также запускаю git config credential.helper store один раз, поэтому мне не нужно указывать uid/pwd при его запуске.

Некоторые говорят, что git commit -am сделает свое дело. Это не сработает, потому что он может только фиксировать изменения в отслеживаемых файлах, но не добавляет новые файлы. Источник.

После некоторых исследований я понял, что такой команды для этого нет, но вы можете написать скрипт в своем .bashrc или .bash_profile в зависимости от вашей ОС.

Я поделюсь тем, что использую сам:

При этом все ваши изменения будут добавлены и зафиксированы, вы можете просто ввести gac, и вам будет предложено написать сообщение о фиксации

Или вы можете ввести свое сообщение о коммите напрямую gac Hello world , все ваши изменения будут добавлены, и ваше сообщение о коммите будет Hello world, обратите внимание, что "" не используются

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

Пожалуйста, см. git-commit(1) для альтернативных способов добавления контента в фиксацию.

Параметры

<р>. Файлы, из которых нужно добавить содержимое. Fileglobs (например, *.c) могут быть заданы для добавления всех соответствующих файлов. Также можно задать начальное имя каталога (например, dir для добавления каталог/файл1 и каталог/файл2) для рекурсивного добавления всех файлов в каталог. -n, --dry-run На самом деле не добавлять файлы, просто показать, существуют ли они. -v, --verbose Многословно.-f, --force Разрешить добавление игнорируемых файлов. -i, --interactive Интерактивно добавить измененное содержимое рабочего дерева в индекс. Могут быть предоставлены необязательные аргументы пути, чтобы ограничить операцию подмножеством рабочего дерева. Подробнее см. в разделе «Интерактивный режим». -p, --patch Интерактивно выбирать фрагменты исправлений между индексом и рабочим деревом и добавлять их в индекс. Это дает пользователю возможность просмотреть разницу, прежде чем добавлять измененное содержимое в индекс.

Это эффективно запускает add --interactive, но пропускает начальное меню команд и сразу переходит к подкоманде patch. Подробнее см. в разделе «Интерактивный режим». -e, --edit Открыть сравнение с индексом в редакторе и позволить пользователю отредактировать его. После закрытия редактора откорректируйте заголовки фрагментов и примените патч к индексу.

ПРИМЕЧАНИЕ. Очевидно, что если вы измените что-либо, кроме первого символа в строках, начинающихся с пробела или минуса, исправление больше не будет применяться. -u, --update Совпадать только с уже отслеженными файлами в индексе, а не с рабочим деревом. Это означает, что он никогда не будет размещать новые файлы, но будет размещать измененное новое содержимое отслеживаемых файлов и удалять файлы из индекса, если соответствующие файлы в рабочем дереве были удалены.

Если не указано, по умолчанию используется "."; другими словами, обновить все отслеживаемые файлы в текущем каталоге и его подкаталогах. -A, --all То же, что и -u, но совпадать с файлами в рабочем дереве в дополнение к индексу. Это означает, что он найдет новые файлы, а также поместит измененный контент и удалит файлы, которых больше нет в рабочем дереве. -N, --intent-to-add Записывать только тот факт, что путь будет добавлен позже. Запись пути помещается в указатель без содержания. Это полезно, помимо прочего, для отображения неустановленного содержимого таких файлов с помощью git diff и их фиксации с помощью git commit -a. --refresh Не добавлять файлы, а только обновлять их информацию stat() в индексе. --ignore-errors Если какие-то файлы не удалось добавить из-за ошибок при их индексации, не прерывайте операцию, а продолжайте добавлять остальные. Команда по-прежнему должна выходить с ненулевым статусом. -- Этот параметр можно использовать для отделения параметров командной строки от списка файлов (полезно, когда имена файлов могут быть ошибочно приняты за параметры командной строки).

Конфигурация

Необязательная переменная конфигурации core.excludesfile указывает путь к файлу, содержащему шаблоны имен файлов для исключения из git-add, аналогично $GIT_DIR/info/exclude. Шаблоны в файле exclude используются в дополнение к шаблонам в info/exclude. См. gitrepository-layout(5).

Примеры

• Добавляет содержимое из всех файлов \*.txt в каталоге Documentation и его подкаталогах: обратите внимание, что звездочка \* в этом примере взята из оболочки; это позволяет команде включать файлы из подкаталогов каталога Documentation/. • Рассматривается добавление содержимого из всех сценариев git-*.sh: поскольку в этом примере оболочка позволяет разворачивать звездочку (т. е. вы явно перечисляете файлы), subdir/git-foo.sh не учитывается.

Интерактивный режим

Читайте также: