Как Вим Коенен выразился , второе определение - репозиторий - это материал внутри каталога .git - фокусируется на организации .
Но Формально я согласен со вторым определением. Оставшаяся область - область, в которой вы выполняете свою работу - не является частью самого репозитория . Это просто рядом с репозиторием.
Причина в том, что содержимое папки .git - это Git s . Вы можете посмотреть на него, и если вы поймете внутреннее устройство Git - которое меняется от одного выпуска Git к другому, по мере того, как Git развивается с течением времени - вы даже можете редактировать вещи прямо здесь. Но в общем, вы должны оставить этот материал самому Git.
Файлы, которые не в папке .git, - это ваши . Вы можете делать с ними все, что хотите. Git будет заполнить вашу рабочую область из фиксации, когда вы попросите об этом.
Таким образом, короткая версия: вы работаете ваше дерево работы. Это ваша область, вы можете делать все, что хотите. Затем вы говорите Git в различные моменты времени: сделать что-то . Это что-то может:
- копировать файлы из вашего рабочего дерева в репозиторий Git; или
- скопировать файлы из репозитория Git в ваше рабочее дерево; или
- выполнить одно из множества других действий, например сравнить определенные коммиты, просмотреть прошлые коммиты, вызвать другой Git репозиторий и обменяться с ним коммитами и так далее.
Это различие - между вашей рабочей областью, которая не является частью собственно репозитория, и областью Git, в которой фактически находится репозиторий - становится еще более важным, если вы используете команда git worktree, впервые добавленная в Git 2.5. В частности, вы можете использовать git worktree add для создания дополнительных рабочих деревьев. Каждое такое дерево работ не в репозитории , и на самом деле вы можете просто удалить такое дерево работ, когда закончите с ним.
( Git называет вашу рабочую область рабочим деревом или рабочим деревом . Вот почему команда, которая добавляет новое рабочее дерево, - git worktree add.)
Основная тема самого Git заключается в том, что Git сохраняет фиксирует . Каждый коммит, в свою очередь, сохраняет файлы. Фактически, каждый коммит содержит полный снимок всех файлов. Сохраненные файлы Git используют дедупликацию, так как большинство коммитов в основном содержат те же версии файлов, что и некоторые другие коммиты. Они также хранятся в специальном формате Git только для чтения. Только Git может фактически читать эти файлы. Вот почему Git извлекает файлы в ваше рабочее дерево.
Особенно странно то, что, когда Git делает новые коммиты - именно так вы Git сохраняете обновленные файлы после вы обновили их - он делает их из копий, которые не копии в вашем рабочем дереве! Если вы когда-либо использовали Mercurial, который в остальном очень похож на Git, это может сбить с толку. В Mercurial hg commit делает новую фиксацию из файлов в вашем рабочем дереве. Это просто и понятно. Но git commit делает новую фиксацию из файлов, которые находятся в Git index , вместо файлов в вашем рабочем дереве. Вы должны продолжать использовать git add, чтобы копировать любые файлы, которые вы обновили, обратно в индекс Git.
Следовательно, Git index - что также Git вызывает промежуточную область - это то, что удерживает вашу предлагаемую следующую фиксацию. В Mercurial, который прост в использовании, ваше рабочее дерево содержит предлагаемую следующую фиксацию. В Git предлагаемая следующая фиксация начинается с совпадения с текущей фиксацией. Когда вы меняете файлы в своем рабочем дереве, вы должны копировать измененные файлы обратно в индекс Git, чтобы изменить предлагаемую следующую фиксацию.
(Метод Git для создания новых коммитов дает вы гибкость, которую труднее достичь в Mercurial, за счет необходимости большого количества git add команд.)
Примечание: в современном Git можно отделить репозиторий Git - папку .git - от вашего рабочего дерева, используя git init --separate-git-dir. Однако я не знаю никого, кто бы использовал это в повседневной работе.