См. ответ Вебена для краткой последовательности используемых команд.
Чтобы понять, что на самом деле происходит, учтите, что в Git есть несколько своеобразное представление о том, как осуществлять контроль версий исходного кода. В частности:
Для Git важны коммиты . В коммите есть некоторые метаданные, например, кто их сделал, когда и почему (сообщение журнала автора), а также полный и полный снимок всех файлов. Коммиты идентифицируются большими уродливыми цепочками букв и цифр. Они называются хэш-идентификаторами , или иногда идентификаторами SHA-1 (Git в настоящее время использует их для создания Secure Hash Algorithm 1) или идентификаторами объектов (OID). Люди иногда называют их хешем коммита (когда они специально предназначены для коммитов - Git использует это и для других вещей).
Файлы в коммитах замораживаются и сжимаются в специальную форму Git-only. (На самом деле, все в коммите замораживается - вы не можете изменить его, вы можете только разморозить его и создать новый и улучшенный и использовать этот вместо старого 1. Это то, что, например, git commit --amend делает.) Поскольку они в форме только для Git, вам нужно место для работы.
Следовательно, Git предоставляет вам рабочее дерево . Здесь ваши файлы имеют свою обычную повседневную форму. Вы можете использовать их, редактировать, заменять и так далее. Git на самом деле совсем не использует эти файлы - он просто предоставляет их, извлеченные из коммита.
Git делает новые коммиты из того, что Git вызывает, по-разному: index , область подготовки или кеш , в зависимости от того, кто / какая часть Git выполняет вызов. Индекс трудно увидеть (вы можете увидеть его - например, попробуйте git ls-files --stage - но обычно в нем слишком много вещей в , чтобы посмотреть на него таким образом). Файлы в индексе находятся в специальной форме Git-only, готовые для фиксации: почти, но не совсем, заморожены.
Команда git add, которую вам нужно будет использовать довольно часто, копирует файл из рабочего дерева - тот, над которым вы работали, или заново созданный, если это так, - в индекс. Он заменяет предыдущую копию, если она была, или помещает новый файл в индекс впервые. Теперь все готово для совершения.
Многие другие команды Git также используют или управляют индексом. Наиболее очевидным является git commit, который берет все, что сейчас находится в индексе, и замораживает его в новый коммит. Менее очевидным является git reset, который - в зависимости от параметров и флагов - копирует файлы из фиксации в индекс и, возможно, также в рабочее дерево. Команда git checkout имеет режим, в котором она также копирует файлы из фиксации в индекс, а затем в рабочее дерево или из индекса в рабочее дерево без предварительного выхода из фиксации.
Когда вы используете git status, чтобы увидеть, что происходит, git status сравнивает текущую (или HEAD) фиксацию индекса. Что бы не отличалось здесь staged for commit. Затем он сравнивает индекс с рабочим деревом. отличается здесь not staged for commit. Поэтому, если вы внесли некоторые изменения, и использовали git add до , скопируйте их в область index / staging, HEAD vs index покажет поэтапные изменения. Если вы еще не использовали git add, HEAD vs index ничего не отобразит, а index-vs-work-tree покажет не измененные изменения.
Индекс часто вызывает боль, и можно было бы пожелать, чтобы Git походил на Mercurial (который не беспокоится о индексе), но он также позволяет вам делать некоторые причудливые трюки. Важно знать, что существует три копии каждого файла: одна в HEAD, одна в индексе и одна в рабочем дереве, а не только замороженная копия HEAD и редактируемая копия рабочего дерева.