Git все файлы с расширением
Обновлено: 05.07.2024
Мы конечно могли бы вручную добавлять нужные файлы в репозиторий, например так:
Однако это было бы очень трудоемко. Гораздо проще использовать команду:
Которая добавит все файлы в каталоге проекта.
Но что если нам не нужны абсолютно все файлы, а есть файлы например в каталоге /cache или /images или /runtime проекта, которые генерируются в процессе работы. Они не должны быть добавлены в репозиторий.
Тут нам и нужен .gitignore. Вам нужно его самим создать и разместить в корне проекта либо нужной подпапке.
Где должен находиться этот файл
Файл может находиться в корне проекта или любом подкаталоге.
Либо можно задать глобальный файл gitignore, таким образом:
Таким образом вы сможете записать в глобальный файл
/.gitignore_global настройки, общие для всех ваших проектов. В нем могут храниться например файлы для игнорирования, которые специфичны для вашей IDE, и по этому не логично добавлять их в репозиторий. Однако файлы, которые специфичны для конкретного проекта, обязательно нужно добавлять в .gitignore самого проекта.
Примеры содержимого .gitignore файла
Подробнее о шаблонах игнорирования
| Шаблон | Примеры соответствия | Пояснение* |
|---|---|---|
| **/logs | logs/debug.log logs/monday/foo.bar build/logs/debug.log | Добавьте в начало шаблона две звездочки, чтобы сопоставлять каталоги в любом месте репозитория. |
| **/logs/debug.log | logs/debug.log build/logs/debug.log но не logs/build/debug.log | Две звездочки можно также использовать для сопоставления файлов на основе их имени и имени родительского каталога. |
| *.log | debug.log foo.log .log logs/debug.log | Одна звездочка — это подстановочный знак, который может соответствовать как нескольким символам, так и ни одному. |
| *.log !important.log | debug.log trace.log но не important.log logs/important.log | Добавление восклицательного знака в начало шаблона отменяет действие шаблона. Если файл соответствует некоему шаблону, но при этом также соответствует отменяющему шаблону, указанному после, такой файл не будет игнорироваться. |
| .log !important/.log trace.* | debug.log important/trace.log но не important/debug.log | Шаблоны, указанные после отменяющего шаблона, снова будут помечать файлы как игнорируемые, даже если ранее игнорирование этих файлов было отменено. |
| /debug.log | debug.log но не logs/debug.log | Косая черта перед именем файла соответствует файлу в корневом каталоге репозитория. |
| debug.log | debug.log logs/debug.log | По умолчанию шаблоны соответствуют файлам, находящимся в любом каталоге |
| debug?.log | debug0.log debugg.log но не debug10.log | Знак вопроса соответствует строго одному символу. |
| debug7.log | debug0.log debug1.log но не debug10.log | Квадратные скобки можно также использовать для указания соответствия одному символу из заданного диапазона. |
| debug[01].log | debug0.log debug1.log но не debug2.log debug01.log | Квадратные скобки соответствуют одному символу из указанного набора. |
| debug[!01].log | debug2.log но не debug0.log debug1.log debug01.log | Восклицательный знак можно использовать для указания соответствия любому символу, кроме символов из указанного набора. |
| debug[a-z].log | debuga.log debugb.log но не debug1.log | Диапазоны могут быть цифровыми или буквенными. |
| logs | logs logs/debug.log logs/latest/foo.bar build/logs build/logs/debug.log | Без косой черты в конце этот шаблон будет соответствовать и файлам, и содержимому каталогов с таким именем. В примере соответствия слева игнорируются и каталоги, и файлы с именем logs |
| logs/ | logs/debug.log logs/latest/foo.bar build/logs/foo.bar build/logs/latest/debug.log | Косая черта в конце шаблона означает каталог. Все содержимое любого каталога репозитория, соответствующего этому имени (включая все его файлы и подкаталоги), будет игнорироваться |
| logs/ !logs/important.log | logs/debug.log logs/important.log | Минуточку! Разве файл logs/important.log из примера слева не должен быть исключен нз списка игнорируемых? Нет! Из-за странностей Git, связанных с производительностью, вы не можете отменить игнорирование файла, которое задано шаблоном соответствия каталогу |
| logs/**/debug.log | logs/debug.log logs/monday/debug.log logs/monday/pm/debug.log | Две звездочки соответствуют множеству каталогов или ни одному. |
| logs/*day/debug.log | logs/monday/debug.log logs/tuesday/debug.log but not logs/latest/debug.log | Подстановочные символы можно использовать и в именах каталогов. |
| logs/debug.log | logs/debug.log но не debug.log build/logs/debug.log | Шаблоны, указывающие на файл в определенном каталоге, задаются относительно корневого каталога репозитория. (При желании можно добавить в начало косую черту, но она ни на что особо не повлияет.) |
Что если файлы из gitignore уже добавлены в репозиторий
Обратите внимание, что если файлы уже добавлены в git репозиторий, то добавление их в .gitignore не удалит эти файлы. Изменения в них будут продолжать отслеживаться и входить в коммиты, несмотря на то, что они есть в .gitignore .
Нам придется вручную их удалить из репозитория.
Очень удобная команда bash, которая удалит из git репозитория те файлы, которые содержатся в файлах .gitignore :
То же самое для Powershell
При выполнении этой команды, файлы останутся у вас на диске, однако из репозитория они будут удалены.
Либо можно удалять файлы вручную, таким образом:
Либо если нам нужно удалить целую директорию из git, то воспользуемся следующей командой:
Либо так мы могли бы удалить все файлы с расширением .log в папке log:
Параметр --cached означает, что файлы будут удалены только из раздела "проиндексированных файлов". На диске (рабочем каталоге) они останутся нетронутыми.
Как понять, почему игнорируется конкретный файл
Запустите команду вместо path/to/file следует указать путь к файлу.
В итоге мы получим ответ, в котором содержится конкретная строка .gitignore, благодаря которой данный файл игнорируется.
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это Git и сервис Github.
Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.
Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.
После того, как вы начали работу над проектом и написали какой-то работающий прототип, у вас появится желание сохранить результаты работы. Это так же может быть полезно в случае, если вы захотите продолжить работу на другом компьютере. Самое простое решение — это сохранить все на флешке. Этот вариант неплохо работает, но если есть подключение к интернету (а сейчас у кого его нет), то удобно воспользоваться системами Git/Github.
В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.
Создание локального репозитория
Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.
Для просмотра папки удобно воспользоваться командой tree, которая покажет не только содержимое каждой папки, но и древовидную структуру директорий.
Часто временные файлы содержат специфические суффиксы, по которым их легко обнаружить и в последствии удалить. Для поиска таких файлов можно воспользоваться командой find. В качестве примера посмотрим, как найти все файлы, которые генерируются компилятором Python и имеют расширение .pyc
Переходим в папку с проектом /home/user/project:
И показываем список файлов с расширением .pyc:
Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:
Очень рекомендуется не спешить и сразу ключ этот не добавлять. Первый раз вызвать команду для просмотра файлов и только убедившись, что в список не попало ничего полезного добавить ключ удаления.
Создадим локальный репозиторий в папке с проектом:
После выполнения этой команды появится новая папка с именем .git. В ней будет несколько файлов и поддиректориев. На данный момент система управления версиями еще не видит наших файлов.
Добавление файлов в локальный репозиторий
Для добавления файлов используется команда:
После выполнения команды, файл readme будет добавлен в систему управления версий (конечно если он уже был то этого в проекте). При добавлении файла генерируется хеш значение, которое выглядит примерно так:
Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:
Что легко увидеть с помощью команды:
Сам файл является архивом, который легко распаковать и вывести на экран, указав полное значение хеша.
Для того, чтобы добавить все файлы из текущей директории введите:
Если нужно добавить файлы из текущей директории и из всех поддиректориев, то используйте:
Для того, чтобы в систему не попадали временные файлы, можно их занести в файл .gitignore, который нужно создать самостоятельно и разместить в корневом каталоге проекта (на том же уровне, что и .git директория).
Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.
После добавления файлов, все изменения находятся в так называемой staging (или cached) area. Это некоторое временнное хранилище, которое используется для накопления изменений и из которого создаются собственно версии проектов (commit).
Для просмотра текущего состояния можно воспользоваться командой:
После выполнения команды мы увидим, что в stage area находится наш файл:
Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.
Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.
Можно отменить добавления файла readme в staging area с помощью команды:
После выполнения команды, файл readme отметится, как неизмененный системой.
Создание версии проекта
После того, как мы добавили нужные файлы в staging area мы можем создать версию проекта. С помощью команды:
Каждая новая версия сопровождается комментарием.
После коммита, мы сможем найти два новых объекта внутри .git репозитория.
Посмотрим, что внутри:
Ключ -t показывает тип объекта. В результате мы видим:
Для второго объекта:
Для самого первого файла:
Если мы будем дальше изучать содержимое этих файлов, то обнаружим древовидную структуру. От каждого коммита можно по ссылкам пройти по всем измененным файлам. Для практического применения это не очень нужно, но возможно так будет легче понять, что происходит при работе с системой Git.
Ключ --no-edit нужен, чтобы не вводить заново комментарий.
Можно просмотреть изменения, которые вы внесли последним коммитом:
Ключ --name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.
Если вы продолжили работать и изменили только те файлы, которые были уже добавлены в систему командой git add, вы можете сделать коммит одной командой:
Для просмотра списка всех коммитов, воспользуйтесь командой:
Ключ --oneline нужен, чтобы уменьшить количество информации выдаваемой на экран. С этим ключем каждый коммит показывается в одну строчку. Например:
Для того, чтобы просмотреть изменения по конкретному коммиту, достаточно в команду git show добавить хеш значение коммита, которое можно получить с помощью предыдущей команды.
Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:
Для того чтобы удалить все файлы в папке, которые не относятся к проекту и не сохранены в репозитории, можно воспользоваться командой:
Создание репозитория на Github
После регистрации нажимаем кнопочку "+" и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.
В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.
Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).
Можем просмотреть результат добавления с помощью команды:
Если все было правильно сделано, то увидим:
Для того, чтобы отменить регистрацию удаленного репозитария введите:
Следующей командой вы занесете все изменения, которые были сделаны в локальном репозитории на Github.
Ключ -u используется для того, чтобы установить связь между удаленным репозиторием github и вашей веткой master. Все дальнейшие изменения вы можете переносить на удаленный репозиторий упрощенной командой.
Перенос репозитория на другой компьютер
После того, как репозиторий был создан на Github, его можно скопировать на любой другой компьютер. Для этого применяется команда:
Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).
Так же можно добавить название папки, в которой вы хотите разместить локальный репозиторий.
Работа с одним репозиторием с разных компьютеров
С одним репозиторием с разных компьютеров может работать несколько разработчиков или вы сами, если например работаете над одним и тем же проектом дома и на работе.
Для получения обновлений с удаленного репозитория воспользуйтесь командой:
Если вы изменили ваши локальные файлы, то команда git pull выдаст ошибку. Если вы уверены, что хотите перезаписать локальные файлы, файлами из удаленного репозитория то выполните команды:
Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.
Как мы уже знаем, для того чтобы изменения выложить на удаленный репозиторий используется команда:
В случае, если в удаленном репозитории лежат файлы с версией более новой, чем у вас в локальном, то команда git push выдаст ошибку. Если вы уверены, что хотите перезаписать файлы в удаленном репозитории несмотря на конфликт версий, то воспользуйтесь командой:
Иногда возникает необходимость отложить ваши текущие изменения и поработать над файлами, которые находятся в удаленном репозитории. Для этого отложите текущие изменения командой:
После выполнения этой команды ваша локальная директория будет содержать файлы такие же, как и при последнем коммите. Вы можете загрузить новые файлы из удаленного репозитория командой git pull и после этого вернуть ваши изменения которые вы отложили командой:
Программы, которые поддерживают GIT расширение файла
Следующий список содержит программы, сгруппированные по 3 операционным системам, которые поддерживают GIT файлы. GIT файлы можно встретить на всех системных платформах, включая мобильные, но нет гарантии, что каждый из них будет должным образом поддерживать такие файлы.
Программы, обслуживающие файл GIT
Как открыть файл GIT?
Причин, по которым у вас возникают проблемы с открытием файлов GIT в данной системе, может быть несколько. К счастью, наиболее распространенные проблемы с файлами GIT могут быть решены без глубоких знаний в области ИТ, а главное, за считанные минуты. Приведенный ниже список проведет вас через процесс решения возникшей проблемы.
Шаг 1. Установите Microsoft Visual Studio программное обеспечение
Основная и наиболее частая причина, препятствующая открытию пользователями файлов GIT, заключается в том, что в системе пользователя не установлена программа, которая может обрабатывать файлы GIT. Наиболее очевидным решением является загрузка и установка Microsoft Visual Studio или одной из перечисленных программ: Eclipse, Apple Xcode, GitHub. В верхней части страницы находится список всех программ, сгруппированных по поддерживаемым операционным системам. Самый безопасный способ загрузки Microsoft Visual Studio установлен - для этого зайдите на сайт разработчика (Microsoft Corporation) и загрузите программное обеспечение, используя предоставленные ссылки.
Шаг 2. Обновите Microsoft Visual Studio до последней версии
Если проблемы с открытием файлов GIT по-прежнему возникают даже после установки Microsoft Visual Studio, возможно, у вас устаревшая версия программного обеспечения. Проверьте веб-сайт разработчика, доступна ли более новая версия Microsoft Visual Studio. Может также случиться, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Если у вас установлена более старая версия Microsoft Visual Studio, она может не поддерживать формат GIT. Самая последняя версия Microsoft Visual Studio обратно совместима и может работать с форматами файлов, поддерживаемыми более старыми версиями программного обеспечения.
Шаг 3. Свяжите файлы Git Repository с Microsoft Visual Studio
Если проблема не была решена на предыдущем шаге, вам следует связать GIT файлы с последней версией Microsoft Visual Studio, установленной на вашем устройстве. Следующий шаг не должен создавать проблем. Процедура проста и в значительной степени не зависит от системы
Выбор приложения первого выбора в Windows
- Выберите пункт Открыть с помощью в меню «Файл», к которому можно щелкнуть правой кнопкой мыши файл GIT.
- Нажмите Выбрать другое приложение и затем выберите опцию Еще приложения
- Наконец, выберите Найти другое приложение на этом. , укажите папку, в которой установлен Microsoft Visual Studio, установите флажок Всегда использовать это приложение для открытия GIT файлы свой выбор, нажав кнопку ОК
Выбор приложения первого выбора в Mac OS
Шаг 4. Проверьте GIT на наличие ошибок
Если проблема по-прежнему возникает после выполнения шагов 1-3, проверьте, является ли файл GIT действительным. Вероятно, файл поврежден и, следовательно, недоступен.
1. Убедитесь, что GIT не заражен компьютерным вирусом
Если случится так, что GIT инфицирован вирусом, это может быть причиной, которая мешает вам получить к нему доступ. Немедленно просканируйте файл с помощью антивирусного инструмента или просмотрите всю систему, чтобы убедиться, что вся система безопасна. Если сканер обнаружил, что файл GIT небезопасен, действуйте в соответствии с инструкциями антивирусной программы для нейтрализации угрозы.
2. Убедитесь, что файл с расширением GIT завершен и не содержит ошибок
3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.
Некоторые файлы требуют повышенных прав доступа для их открытия. Войдите в систему, используя учетную запись администратора, и посмотрите, решит ли это проблему.
4. Убедитесь, что в системе достаточно ресурсов для запуска Microsoft Visual Studio
Если в системе недостаточно ресурсов для открытия файлов GIT, попробуйте закрыть все запущенные в данный момент приложения и повторите попытку.
5. Убедитесь, что у вас установлены последние версии драйверов, системных обновлений и исправлений
Последние версии программ и драйверов могут помочь вам решить проблемы с файлами Git Repository и обеспечить безопасность вашего устройства и операционной системы. Возможно, файлы GIT работают правильно с обновленным программным обеспечением, которое устраняет некоторые системные ошибки.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла GIT мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле GIT.
Начало использования Git напоминает посещение новой страны, языка которой вы не знаете. Пока ясно, где вы и куда идти, все хорошо, но стоит заблудиться — и начинаются большие проблемы.
В интернете размещена масса руководств по командам Git, но в этой статье работа Git рассмотрена глубже, чем просто изучение команд.
Наверное, единственный путь преодолеть все эти трудности — узнать чуть больше, чем просто git commit/push, понять, как именно работает Git.
Папка .git
Когда вы создаете новый репозиторий командой git init, Git создает волшебную папку, .git. В ней содержится все необходимое для работы Git. Если вы хотите убрать Git из вашего проекта, но оставить проектные файлы на диске, просто удалите папку .git. Хотя кому такое может потребоваться?
Вот содержимое типовой папки .git перед вашим первым коммитом:
- HEAD — это мы рассмотрим позже.
- config — этот файл содержит настройки для вашего репозитория, здесь, например, хранится url вашего репозитория в хранилище, ваше имя, email и так далее. Каждый раз когда вы делаете git config, вы обращаетесь к этому файлу.
- description — используется gitweb для отображения описания репозитория.
- hooks — эта папка содержит скрипты, которые могут выполняться на различных этапах выполнения Git. Эти скрипты, называемые хуками, могут запускаться до/после commit/rebase/pull… Имя скрипта определяет время его выполнения. Примером хука может служить скрипт проверки стиля перед выполнением команды push в репозиторий.
- info — exclude — здесь описываются файлы, которые вы не хотите включать в репозиторий. Функционал этого файла такой же, как у файла .gitignore, за исключением того, что он не передается в репозиторий. На практике обычно для всех задач хватает .gitignore.
Что внутри коммита?
Каждый раз, когда вы создаете файл и коммитите изменения, Git архивирует файл и сохраняет его в своей структуре данных. Архивированный объект создается с уникальным именем и хранится в папке объектов.
Перед изучением папки объектов уточним, что же такое коммит. Коммит — это слепок текущего состояния файлов в рабочей папке, но не только это.
По факту, когда вы коммитите изменения, Git производит всего два действия:
- Если файл в рабочей папке не изменялся, он просто добавляет имя сжатого файла (хеш) в снимок.
- Если файл в рабочей папке изменялся, он сжимает его, помещает в папку объектов и добавляет имя сжатого файла (хеш) в снимок.
Как только снимок сделан, он также архивируется и именуется при помощи хеша, затем помещается в папку объектов.
Вот как выглядит папка объектов после того, как я создал файл file_1.txt и закоммитил его. Пожалуйста, учтите, что если хеш вашего файла начинается на «4cf44f1e…», то Git сохранит его с именем «f44f1e…» в подпапке с именем «4c». Таким образом, файлы будут разложены по 256 подпапкам и в каждой не будет слишком много файлов.
У нас, как вы видите, три хеша. Один для файла file_1.txt, второй для снимка, сделанного при коммите. Для чего же третий? Третий хеш создается потому, что коммит — тоже объект, он также архивируется и помещается в папку объектов.
Вам нужно запомнить, что коммит состоит из четырех вещей:
- Имя (хеш) снимка рабочей директории.
- Комментарий.
- Информация о том, кто выполнил коммит.
- Хеш родительского коммита.
И вот, что вы увидите:
Вы видите, как и ожидалось, хеш снимка, автора и комментарий коммита. Тут важны две вещи:
- Хеш снимка «86550. » также является объектом и его можно увидеть в папке объектов.
- Так как это первый коммит, у него нет родительского коммита.
Здесь мы видим объект, который находился в нашем хранилище объектов, единственный объект в нашем снимке.
Branch, tags, HEAD — это одно и то же
Теперь вы понимаете, что все в Git может быть получено через правильный хеш. Давайте теперь посмотрим на HEAD. Итак, что же там?
Там нет хеша, и в этом есть смысл, так как HEAD — это указатель на верхушку ветви, с которой вы работаете. Если вы посмотрите в файл refs/heads/master, то увидите:
Выглядит знакомо? Естественно, ведь это хеш первого коммита! Это показывает, что теги (tags) и ветви (branch) — всего лишь указатели на коммит. Понимая это, вы можете удалить все теги, какие захотите, все ветви, какие захотите, а коммит, на который они указывали, останется на месте. Единственное, к нему будет сложнее получить доступ. Если вам хочется больше узнать об этом, почитайте git book.
Последнее замечание
После прочтения для вас должно стать очевидным, что все, что делает Git — архивирует вашу рабочую папку и помещает ее в папку объектов с некоторым количеством дополнительной информации. Если вы достаточно знакомы с Git, то вы полностью контролируете, какие файлы будут включены в коммит, а какие нет.
Я считаю, что коммит — это не снимок рабочей папки, а снимок файлов, которые вы хотите коммитить. И где Git хранит список файлов, которые вы хотите коммитить? Он сохраняет этот список в индексном файле. Мы не будем сильно углубляться в этот вопрос, если вам интересно, подробнее можно посмотреть здесь.
Читайте также: