Что такое папка .git?

Ответ 1

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

Основная структура выглядит следующим образом:

.
|-- COMMIT_EDITMSG
|-- FETCH_HEAD
|-- HEAD
|-- ORIG_HEAD
|-- branches
|-- config
|-- description
|-- hooks
|   |-- applypatch-msg
|   |-- commit-msg
|   |-- post-commit
|   |-- post-receive
|   |-- post-update
|   |-- pre-applypatch
|   |-- pre-commit
|   |-- pre-rebase
|   |-- prepare-commit-msg
|   `-- update
|-- index
|-- info
|   `-- exclude
|-- logs
|   |-- HEAD
|   `-- refs
|-- objects
`-- refs
    |-- heads
    |-- remotes
    |-- stash
    `-- tags

•   
• COMMIT_EDITMSG: Это последнее сообщение коммитов. Его фактически не используется Git вообще, но его там в основном для вашей справки после совершения фиксации.  
• config: содержит настройки для этого репозитория. Здесь могут быть сброшены конкретные конфигурационные переменные (и даже aliases!). Для чего этот файл больше всего используется, это определение того, где живут пульты и какое-то ядро настройки, например, если ваш репозиторий голый или нет.  
• description: Если вы используете gitweb или запускаете git instaweb, это будет отображаться при просмотре вашего репозитория или список всех репозитариев версий.  
• FETCH_HEAD: SHA ветки/удаленных голов, которые были обновлены во время последнего git fetch  
• HEAD: Текущий рефер, на который вы смотрите. В большинстве случаев, вероятно, refs/heads/master  
• index: промежуточная область с метаданными, такими как временные метки, имена файлов, а также SHA файлов, которые уже завернуты на Git.  
• packed-refs: Убирает dormant refs, это не окончательный список ссылок в вашем репозитории (папка refs имеет настоящие!) Взгляните на комментарий gitsters, чтобы увидеть дополнительную информацию об этом.  
• ORIG_HEAD: При выполнении слияния это SHA ветки, с которой вы объединяетесь.  
• MERGE_HEAD: При выполнении слияния это SHA ветки, с которой вы сливаетесь.  
• MERGE_MODE: используется для связи ограничений, которые были первоначально заданы для git merge до git commit при конфликте слияния, и для завершения этого требуется отдельный git commit. В настоящее время --no-ff - это единственные ограничения, прошедшие этот путь.  
• MERGE_MSG: перечисляет конфликты, которые происходят во время вашего текущего слияния.  
• RENAMED-REF: все еще пытаюсь отследить это. Из базового grep через источник кажется, что этот файл связан с ошибками при сохранении ссылок.

Также есть множество каталогов:

•   
• hooks: каталог, который быстро станет вашим лучшим другом: в нем содержатся скрипты, которые выполняются в определенное время при работе с Git, например, после фиксации или перед переустановкой. Вся серия статей будет касаться крючков.  
• info: Относительно неинтересно, кроме файла exclude, который живет внутри него. Мы видели это ранее в статье ignoring files, но в качестве напоминания вы можете использовать этот файл для игнорирования файлов для этого проекта, но будьте осторожны! Его версией не является файл .gitignore.  
• logs: Содержит историю для разных ветвей. Кажется, используется в основном с помощью команды reflog.  
• objects: Git s внутренний склад blobs, все индексируются SHA.  
• rebase-apply: Workbench для rebasing и для git am. Вы можете вставить его в файл patch, если он не применяется чисто, если вы смелый.  
• refs: основная копия всех ссылок, которые находятся в вашем репозитории, будь то для закладок, тегов, ветвей удаленного отслеживания или локальных ветвей.

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

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

Ответ 2

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

Для получения дополнительной информации вы можете проверить официальный сайт Git.

Ответ 3

Это объяснение должно помочь новичкам понять папку .git.

Папка .git немного похожа на волшебную шляпу, в которую вы помещаете свое текущее волшебное шоу.

Когда вы создаете новый репозиторий git (git init), все, что вы организуете в формат шоу, помещается внутри этой волшебной шляпы и может быть "извлечено" в любое время и в любом месте.

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

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

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

git rm говорит папке .git прекратить позволять что-то вытаскивать из шляпы, например, представьте, если вы больше не хотите, чтобы кролик был частью вашего магического шоу. (Важно отметить, что вы все еще можете восстановить предыдущую версию вашего шоу, которая будет включать кролика (ваша версия блога 1999 года с Comic Sans), если вы действительно этого хотите, но ваше текущее шоу не будет включать кролика, если вы использовал git rm).

Ответ 4

.git инициализируется git init.

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

4 подкаталога:

• крючки /
• info/: exclude файл для игнорируемых шаблонов
• объекты /: все "объекты"
• refs/: указатели для фиксации объектов

4 файла:

• ГОЛОВА: текущая ветвь
• config: параметры конфигурации
• описание
• индекс: площадка

Здесь "объект" включает в себя:

• Blobs (файлы)
• деревья (каталоги)
• коммиты (ссылка на дерево, parrent commit и т.д.)

Ответ 5

Папка .git - это каталог, который создается при выполнении git init (в случае нового проекта) или при выполнении git clone (в случае извлечения проекта из другого места). Это "вещь", которая делает ваш проект "git" хранилищем. Без .git ваш проект является локальным, а не git-проектом, это означает, что вы не можете выполнять никакие git-операции.

git хранит метаданные и объектную базу данных для проекта в этом каталоге, например:

1. Удаленная информация (к какому удаленному серверу подключен ваш проект)
2. История всех локальных коммитов
3. Информация о ветке (на какую ветку указывает текущее состояние вашего проекта (HEAD))
4. Все журналы всех локальных коммитов, которые вы когда-либо делали (включая отмену изменений)

Чтобы узнать больше, ознакомьтесь с официальной документацией из git: https://git-scm.com/book/en/v1/Git-Basics-Getting-a-Git-Repository

Ответ 6

В основном, это означает, что ваш каталог обрабатывается Git (Git репозиторий). Если вы переместите его в другое место (или удалите его), вы столкнетесь с чем-то вроде:

fatal: не репозиторий Git (или любой из родительских каталогов):.git

каждый раз, когда вы используете команду git * '.

Вы можете перемещать каталог .git где-то еще, используя:

git - git -dir =/myproject_path/myproject.git log --oneline

Или:

export GIT_DIR =/myproject_path/myproject.git

Но я не рекомендую это делать. Обратите внимание, что это только 1 папка, в отличие от SVN.

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

Возможно, самый "известный" файл внутри - это файл config, который содержит всю информацию о ваших ветких.

Рекомендовать читать здесь подробнее..