git add — В чем разница между git add ., add -A, add -u и add *?

Давайте обозначим категории файлов, которые вообще можно добавлять. Будем использовать те же обозначения, что и в выводе команды git status -s:

M — (modified) отслеживаемые, изменились с прошлого коммита, еще не добавлены
D — (deleted) отслеживаемые, удалены после прошлого коммита, еще не добавлены
? — (untracked) неотслеживаемые, не запрещены к добавлению
! — (ignored) неотслеживаемые, запрещены к добавлению (например, в .gitignore)

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

Путь . обозначает текущую директорию, т.е. ту, в которой была запущена команда.

Начиная с Git версии 2.0, поведение команды add приведено в соответствие с поведением commit и других комманд.

Теперь . обозначает не всю рабочую область (working tree), а текущий путь в этой области.

Таким образом, если вы выполняете команду add не в корневой директории проекта (той, где лежит .git/), то будет обработано содержимое только текущей директории.

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

# работает одинаково из любой директории, добавляет всю рабочую область
git add :/
# путь относительно корневой директории
git add :/path/to/files/
# работает только в текущей директории
cd test
git add .
# эквивалентно этому:
git add :/test
# путь относительно текущей директории
cd test
git add ./path
# эквивалентно этому:
git add :/test/path

Если не указан никакой путь к добавляемым файлам, то большинство команд работает во всей рабочей области, а git add и git add --no-all просто не работают.

git add . 
git add '*'

Git версии 2.0+ просматривает текущую папку и добавляет файлы M, D, ?.
Git версии 1.х просматривает всю рабочую область и добавляет файлы M, D.

Если '*' дается в кавычках, то обрабатывать его будет Git и это эквивалентно

git add .. Исключение: из-под cmd.exe git add '*' не сработает, используйте git add . или git add *.

git add --no-all :/
git add --ignore-removal :/

Эта команда в Git v. 2.0+ работает как git add . в Git v. 1.x, то есть добавляет измененные и новые файлы M, ? во всей рабочей области. Для этой команды обязательно указывать путь.

git add --no-all . #добавляет измененные и новые файлы в *текущей директории*
git add --no-all path2/ path3/ # добавляет измененные и новые файлы в путях *относительно текущей директории*

git add -u
git add -update

Git обновляет (update) статус уже отслеживаемых файлов т. е. M, D.

git add -A
git add --all
git add --no-ignore-removal

Эти варианты эквивалентны и добавляют M, D, ?.

Без точки — из всей рабочей области:

git add -A = git add -A :/ = git add :/ + git add -u

С точкой — только текущий путь:

git add -A . = git add . + git add -u .

 
 git add *

Этот синтаксис лучше не использовать, и вот почему:

При этой команде shell (или bash или другая командная оболочка) просматривает рабочую область и отдает Git список файлов на добавление. Система сработает таким образом, что будут найдены абсолютно все не-скрытые файлы, находящиеся в заданном корне. Вы можете посмотреть на этот список, выполнив echo *. ( Исключение: из-под cmd.exe git add * работает так же как git add '*' на shell/bash. )

Произойдет следующее (здесь мы видим сразу несколько причин не использовать add *

):

  1. Добавятся не изменившиеся с прошлого коммита файлы. Git спокойно и молча «прожует» этот запрос, не влияющий на индекс.
  2. Будут добавлены в индекс файлы в не-скрытых папках M,?.
  3. Не будут добавлены файлы в скрытых папках. .M, .?
  4. Не будут добавлены удаленные файлы D.
  5. Если будут захвачены игнорируемые файлы !, то будет попытка их добавить. Git отменит всю операцию и покажет сообщение об ошибке.

Разнообразие параметров (-u, -A, --no-all) нужно для того, чтобы можно было добавлять разные группы файлов. Конкретно --no-all . было добавлено для того, чтобы реализовывать старое поведение

add . в версиях 1.х.

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

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

Основы Git за 5 минут

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

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

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

Вот о чем поговорим:

  1. Git clone.
  2. Git checkout.
  3. Git pull.
  4. Git add и commit.
  5. Git stash и merge.
  6. Git push.

Git clone

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

Допустим, вы захотели клонировать репозиторий со скриншота, представленного выше. Для начала скопируйте ссылку клонирования (см. выше). Затем откройте терминал и через cd перейдите в область на компьютере, куда будут копироваться файлы. Если вы хотите клонировать ветку master, то напечатайте git clone и вставьте ссылку, как это показано ниже:

git clone https://github.com/JamesOkunlade/old-apple.git

Для клонирования определенной ветки репозитория сделайте следующее:

git clone https://github. com/JamesOkunlade/old-apple.git -b branch-name

Git checkout

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

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

Если ветка уже создана:

git checkout branch-name

Если вы создаете новую ветку опций:

git checkout -b branch-name

Git pull

Ваша команда или коллега-разработчик могут изменять ветки репозитория. И каждый раз перед написанием кода вы должны вливать эти изменения в ветку, с которой будете работать. Перейдите в ветку через checkout и выполните команду git pull. Последние изменения будут влиты в локальный репозиторий.

Git add и commit

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

Для захвата всех файлов (кроме исключений изgit ignore) понадобится git add. Захват текущего состояния отдельно взятого файла (к примеру, index.html) делается через git add index.html.

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

git commit -m ‘commit message’

Сообщение в коммите должно пояснить специфику сохраняемых снимков. Например:

git add index.html

git commit -m ‘создание кнопки формы опции’

Две команды можно объединить через оператор&&:

git add index. html && git commit -m ‘создание html структуры футера’

Git stash и merge

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

git merge – это команда, которая сливает два разных снимка репозитория. Вы можете сливать разные снимки изменений одной и той же ветви, сделанные разными разработчиками. Либо же можно сливать разные снимки разных веток.

При переходе в ветку master команда git merge сливает ветку dev с master и наоборот.

Git push

По аналогии с тем, как вы сохраняете снимки в Google Фото, и их видят другие люди, имеющие доступ, git push отправляет локальный репозиторий на сервер, доступный другим пользователям.

git push -u origin branch-name

Перевод статьи James Okunlade: The essentials of Git explained in five minutes

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

Рабочий процесс | Введение в Git

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

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

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

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

# Создаем новый проект
mkdir hexlet-git
# Переходим в созданную директорию
cd hexlet-git
# Выполняем инициализацию
git init
Initialized empty Git repository in /private/tmp/hexlet-git/.git/

Команда git init создает репозиторий — директорию .git, которая содержит все необходимые для работы Git-файлы.

С помощью команды git status можно посмотреть статус репозитория:

git status
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)

В этом выводе указано, что репозиторий пустой (No commits yet) и в него нечего добавить, так как нет новых или измененных файлов. Давайте попробуем добавить несколько файлов:

# Создаем файл README.md со строкой текста
echo 'Hello, Hexlet!' > README.md
echo 'Haskell Curry' > PEOPLE.md

Теперь снова смотрим на статус:

git status
# Часть вывода убрана
Untracked files:
  (use "git add <file>. .." to include in what will be committed)
    PEOPLE.md
    README.md

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

неотслеживаемые (untracked files). Git не следит за изменениями в таких файлах, так как они не добавлены в репозиторий. Добавление в репозиторий происходит в два шага. Первым шагом выполняется команда подготовки файлов git add <путь до файла>:

# Для каждого нового или измененного файла
git add README.md

Смотрим что произошло:

git status
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   README.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    PEOPLE.md

Файл README.md теперь находится в состоянии «подготовлен к коммиту» или, другими словами, файлы попадают в индекс. Под коммитом понимается окончательное добавление в репозиторий, когда Git запоминает файл навсегда и следит за всеми последующими изменениями.

Коммит — это операция, которая берет все подготовленные изменения (они могут включать любое количество файлов) и отправляет их в репозиторий как единое целое. Вот, как он выполняется:

git commit -m 'add README.md'
[main (root-commit) 3c5d976] add README.md
1 file changed, 1 insertion(+)
create mode 100644 README.md

Флаг -m означает message, то есть описание коммита. Коммит можно выполнять и без него, но тогда откроется редактор, в котором нужно будет ввести описание коммита. Мы рекомендуем делать осмысленные описания — это хороший тон. Пример соглашения по именованию коммитов приведен в дополнительных материалах к уроку.

Может возникнуть вопрос: зачем так сложно, зачем отдельно нужен индекс (куда попадают файлы после git add), и почему нельзя добавлять все измененные файлы сразу в коммит? Как ни странно, такой процесс создан как раз для удобства программистов. Дело в том, что во время разработки может меняться и добавляться много файлов. Но это не значит, что мы хотим добавить все эти изменения в один коммит.

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

Теперь файл README.md находится внутри репозитория. Убедиться в этом можно, запустив команду git status:

git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    PEOPLE.md

Команда git status не выводит файлы, которые добавлены в репозиторий и не содержат изменений. При этом сам файл README.md находится внутри директории hexlet-git.

Самостоятельная работа
  1. Выполните все шаги из урока

  2. Добавьте файл PEOPLE.md в репозиторий. После добавления команда git status покажет такой вывод:

    git status
On branch main
nothing to commit, working tree clean
Дополнительные материалы
  1. Git Cheatsheet
  2. Соглашение об именовании коммитов
  3. Что такое Git?

Вам ответят команда поддержки Хекслета или другие студенты.

Сохранение изменений | Atlassian Git Tutorial

При работе в Git или других системах управления версиями концепция «сохранения» представляет собой более тонкий процесс, чем сохранение в текстовом процессоре или других традиционных приложениях для редактирования файлов. Традиционное программное выражение «сохранение» является синонимом термина Git «фиксация». Коммит — это Git-эквивалент «сохранения». Традиционное сохранение следует рассматривать как операцию файловой системы, которая используется для перезаписи существующего файла или записи нового файла. В качестве альтернативы, Git commit — это операция, которая воздействует на набор файлов и каталогов.

Сохранение изменений в Git и SVN — это тоже другой процесс. SVN Commits или «check-in» — это операции, которые делают удаленную отправку на централизованный сервер. Это означает, что для фиксации SVN требуется доступ в Интернет, чтобы полностью «сохранить» изменения проекта. Коммиты Git можно записывать и создавать локально, а затем при необходимости отправлять на удаленный сервер с помощью команды git push -u origin main . Разница между этими двумя методами является фундаментальным отличием архитектурных проектов. Git — это модель распределенного приложения, тогда как SVN — это централизованная модель. Распределенные приложения, как правило, более надежны, поскольку у них нет единой точки отказа, как у централизованного сервера.

Git имеет дополнительный механизм сохранения, который называется «заначка». Тайник — это временная область хранения изменений, которые не готовы к фиксации. Тайник работает с рабочим каталогом, первым из трех деревьев, и имеет широкие возможности использования. Чтобы узнать больше, посетите страницу git stash .

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

гит добавить

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

В сочетании с этими командами вам также потребуется git status для просмотра состояния рабочего каталога и промежуточной области.

Как это работает

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

Разработка проекта вращается вокруг базового шаблона редактирования/стадии/фиксации. Сначала вы редактируете свои файлы в рабочем каталоге. Когда вы будете готовы сохранить копию текущего состояния проекта, вы вносите изменения с помощью git добавить . После того, как вы довольны подготовленным снимком, вы фиксируете его в истории проекта с помощью git commit . Команда git reset используется для отмены фиксации или промежуточного снимка.

В дополнение к git add и git commit третья команда git push необходима для полного совместного рабочего процесса Git. git push используется для отправки зафиксированных изменений в удаленные репозитории для совместной работы. Это позволяет другим членам команды получить доступ к набору сохраненных изменений.

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

Площадка для подготовки

Основная функция команды git add — продвигать ожидающие изменения в рабочем каталоге в область git staging . Промежуточная область — одна из самых уникальных функций Git, и может потребоваться некоторое время, чтобы разобраться с ней, если вы работаете с SVN (или даже с Mercurial). Это помогает думать об этом как о буфере между рабочим каталогом и историей проекта. Промежуточная область считается одним из «трех деревьев» Git, наряду с рабочим каталогом и историей коммитов.

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

Общие опции 

 git add

Подготовьте все изменения в для следующего коммита.

 git add

Подготовить все изменения в для следующего коммита.

 git add -p

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

Примеры

Когда вы начинаете новый проект, git add выполняет ту же функцию, что и svn import . Чтобы создать первоначальную фиксацию текущего каталога, используйте следующие две команды:

 git add . 
 git commit

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

 git add hello.py 
 git commit

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

Резюме

В обзоре git add — это первая команда в цепочке операций, которая предписывает Git «сохранить» моментальный снимок текущего состояния проекта в истории коммитов. При самостоятельном использовании git add будет продвигать ожидающие изменения из рабочего каталога в промежуточную область. Команда git status  используется для проверки текущего состояния репозитория и может использоваться для подтверждения продвижения git add . Команда git reset используется для отмены git add . Затем команда git commit используется для фиксации моментального снимка промежуточного каталога в истории фиксации репозиториев.

Git — git-add Документация

ИМЯ

git-add — Добавить содержимое файла в индекс

ОБЗОР 

  git add  [--verbose | -v] [--пробный | -n] [--сила | -f] [--интерактивный | -i] [--патч | -п]
[--редактировать | -e] [--[no-]все | --[no-]игнорировать-удаление | [--обновить | -u]] [--sparse]
[--намерение добавить | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--renormalize]
[--chmod=(+|-)x] [--pathspec-from-file=<файл> [--pathspec-file-nul]]
[--] […​]

ОПИСАНИЕ

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

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

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

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

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

См. git-commit[1] для альтернативных способов добавления контента в совершить.

ОПЦИИ

…​

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

Дополнительные сведения о синтаксисе см. в записи pathspec . в гитглоссарии[7].

-н
— пробный запуск

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

-в
—подробный

Будьте многословны.

-ф
—сила

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

—разреженный

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

-я
—интерактивный

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

-р
—патч

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

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

-е
—редактировать

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

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

-у
—обновление

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

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

-А
—все
—не-игнорировать-удаление

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

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

—нет-все
—игнорировать удаление

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

Этот параметр предназначен в первую очередь для помощи пользователям, привыкшим к более старым версий Git, чье «git add …​» было синонимом для «git add —no-all …​», т. е. игнорирование удаленных файлов.

-Н
— намерение добавить

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

—обновить

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

—игнорировать ошибки

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

—игнорировать-отсутствует

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

—no-warn-embedded-repo

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

—перенормировать

Применить «чистый» процесс заново ко всем отслеживаемым файлам, чтобы принудительно добавить их снова в индекс. Это полезно после изменение конфигурация core.autocrlf или атрибут text чтобы исправить файлы, добавленные с неправильным окончанием строки CRLF/LF. Эта опция подразумевает -u . Одиночные символы CR остаются нетронутыми, поэтому в то время как CRLF очищается до LF, последовательность CRCRLF только частично очищен до CRLF.

—chmod=(+|-)x

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

—pathspec-from-file=<файл>

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

—pathspec-файл-ноль

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

—

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

ПРИМЕРЫ

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

     $ git добавить документацию/\*.txt

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

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

     $ git добавить git-*.sh

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

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

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

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

 *** Команды ***
      1: статус 2: обновление 3: отменить 4: добавить неотслеживаемый
      5: патч 6: diff 7: выход 8: помощь
    Что теперь > 1

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

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

статус

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

 поэтапный неустановленный путь
     1: бинарное ничего foo.png
     2: +403/-35 +1/-1 git-add--interactive.perl

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

обновление

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

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

 поэтапный неустановленный путь
  1: бинарное ничего foo.png
* 2: +403/-35 +1/-1 git-add--interactive.perl

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

 Обновление>> -2

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

вернуть

Интерфейс очень похож на обновление , а поэтапный информация для выбранных путей возвращается к ГЛАВНАЯ версия. Возврат новых путей делает их неотслеживаемыми.

добавить неотслеживаемый

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

патч

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

 г - поставить этот кусок
n - не ставить этот кусок
д - выйти; не ставить этот кусок или любой из оставшихся
a - подготовить этот фрагмент и все последующие фрагменты в файле
d — не размещать этот фрагмент или любой из последующих фрагментов в файле.
g - выберите кусок, чтобы перейти к
/ - поиск фрагмента, соответствующего заданному регулярному выражению
j - оставить этот фрагмент неопределенным, посмотреть следующий неопределенный фрагмент
J - оставить этот фрагмент нерешенным, см.  следующий фрагмент
k - оставить этот фрагмент неопределенным, см. предыдущий неопределенный фрагмент
K - оставить этот фрагмент нерешенным, см. предыдущий фрагмент
s - разбить текущий кусок на более мелкие куски
e - вручную отредактировать текущий ханк
? - распечатать справку

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

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

дифференциал

Позволяет просмотреть, что будет зафиксировано (т. е. между ГОЛОВА и указатель).

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

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

добавленный контент

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

удаленный контент

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

измененное содержимое

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

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

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

удаление нетронутого содержимого

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

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

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

новый контент

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

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

  • добавление контекста (» «) или удаление («-«) строк

  • удаление контекста или удаление строк

  • изменение содержимого контекста или удаление строк

КОНФИГУРАЦИЯ

Все, что ниже этой строки в этом разделе, включено выборочно из документации git-config[1]. Содержание такое же как то, что там найдено:

add.ignoreErrors
add.ignore-errors (устарело)

Сообщает git add продолжать добавлять файлы, когда некоторые файлы не могут быть добавлено из-за ошибок индексации. Эквивалент --игнорировать ошибки опция git-add[1]. add.ignore-errors устарело, поскольку он не соответствует обычному соглашению об именах для конфигурации переменные.

add.interactive.useBuiltin

Установите значение false , чтобы вернуться к исходной реализации Perl интерактивная версия git-add[1] вместо встроенной версия. Является ли правдой по умолчанию.

СМ. ТАКЖЕ

git-статус[1] git-rm[1] git-сброс [1] git-мв[1] git-коммит[1] git-обновление-индекс[1]

GIT

Часть пакета git[1]

Руководства по Git — git add · GitHub

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

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

Когда вы используете

git add ?
 git add README.md

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

Что делает Git Add?

git add [имя файла] выбирает этот файл и перемещает его в промежуточную область, помечая его для включения в следующую фиксацию. Вы можете выбрать все файлы, каталог, определенные файлы или даже определенные части файла для подготовки и фиксации.

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

git add и git commit идут рука об руку. Они не работают, когда они не используются вместе. И они оба работают лучше всего, когда используются с учетом их совместной функциональности.

Как использовать

git add

Обычное использование и параметры для

git add
  • git add <путь> : Подготовить определенный каталог или файл
  • git добавить . : Подготовить все файлы (которые не указаны в .gitignore ) во всем репозитории
  • git add -p : Интерактивная стадия изменений

Вы можете увидеть все многочисленные параметры с помощью git add в документации git-scm.

Примеры

git add

git add обычно вписывается в рабочий процесс в следующих шагах:

  1. Создание ветки: git branch update-readme
  2. Проверка в этой ветке: git checkout update-readme
  3. Изменить файл или файлы
  4. Сохраните файл или файлы
  5. Добавьте файлы или сегменты кода, которые должны быть включены в следующую фиксацию: git add README.md
  6. Зафиксируйте изменения: git commit -m «обновите README, чтобы включить ссылки на руководство по внесению изменений»
  7. Отправьте изменения в удаленную ветку: git push -u origin update-readme

Но git add также можно использовать как:

  1. Создать ветку: git branch update-readme
  2. Проверка в этой ветке: git checkout update-readme
  3. Изменить файл или файлы
  4. Сохраните файл или файлы
  5. Добавить только один файл или часть измененного файла: git add README. md
  6. Зафиксируйте первый набор изменений: git commit -m "обновите README, чтобы включить ссылки на руководство по внесению вклада"
  7. Добавить другой файл или другую часть измененного файла: git add CONTRIBUTING.md
  8. Зафиксируйте второй набор изменений: git commit -m "создать вспомогательное руководство"
  9. (Повторите при необходимости)
  10. Отправьте изменения в удаленную ветку: git push -u origin update-readme

git add All Files

Подготовка всех доступных файлов — популярная, хотя и рискованная операция. Это может сэкономить время, но сопряжено с двойным риском:

Плохо продуманная история

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

Случайное размещение и фиксация файлов

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

Принятие решения о подготовке всех файлов

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

  • git add -A : размещает все файлы, включая новые, измененные и удаленные файлы, включая файлы в текущем каталоге и в более высоких каталогах, которые все еще принадлежат тому же репозиторию git
  • git добавить . : рекурсивно добавляет весь каталог, включая файлы, имена которых начинаются с точки
    • .
  • git add -u : этапы только измененных и удаленных файлов, НЕ новых файлов
Новые файлы Модифицированные файлы Удаленные файлы Файлы с именами, начинающимися с точки Текущий каталог Высшие справочники
git добавить -A Да Да Да Да Да Да
git добавить . Да Да Да Да Да №
git добавить -u № Да Да Да Да Да

git add Папка или конкретный файл

Самый безопасный и понятный способ использования git add — указать конкретный файл или каталог для подготовки. Синтаксис для этого может выглядеть так:

git add directory/ : внести все изменения во все файлы в каталоге под названием 9. 0005 каталог
git add README.md : внесите все изменения в файл README.md

Отменить добавленные файлы

Работа. Невозможно «отменить» добавление так же, как вы можете отменить фиксацию, но вы можете переместить файлы из промежуточной области.

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

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

Использование
git reset для отмены git add

git reset — гибкая и мощная команда. Одним из его многочисленных вариантов использования является перемещение изменений 90 153 из 90 154 промежуточной области. Для этого используйте «смешанный» уровень сброса, который установлен по умолчанию.

Чтобы переместить поэтапные изменения из промежуточной области в рабочий каталог, не затрагивая зафиксированную историю, сначала убедитесь, что у вас нет дополнительных изменений в рассматриваемых файлах, как указано выше. Затем введите git reset HEAD (он же git reset --mixed HEAD ).

Связанные термины

  • git status : всегда хорошая идея, эта команда показывает, в какой ветке вы находитесь, какие файлы находятся в рабочем или промежуточном каталоге, а также любую другую важную информацию.
  • git checkout [название ветки] : переключается на указанную ветку и обновляет рабочий каталог.
  • git commit -m «описательное сообщение» : снимки файлов постоянно записываются в историю версий.

    No related posts.