Git все файлы с расширением
Is there a way to ignore all files of a type in a directory?
** is apparently meaningless to git, so this doesn't work:
The idea is to match arbitrary nested folders.
Несколько улучшений git stash
Если вы фанат git rebase, то, скорее всего, знакомы с опцией --autostash. Она автоматически сохраняет все локальные изменения во временное хранилище (stash) до выполнения rebase, а после его завершения применяет их снова.
Это удобно, поскольку можно делать rebase на «грязной» рабочей копии. Для ещё большего удобства существует параметр rebase.autostash, который делает описанное поведением по умолчанию. Применить его глобально можно с помощью команды:
Этот параметр существует ещё с Git 1.8.4, но в Git 2.7 добавлена возможность отменить его с помощью опции --no-autostash. Скорее всего, эта опция добавлена для полноты, поскольку единственное, что она даёт при попытке выполнить rebase на «грязной» рабочей копии, — это соответствующее предупреждение:
Говоря о конфигурации, стоит также упомянуть о параметре stash.showPatch, который также появился в Git 2.7. При стандартных настройках команда git stash show выводит только краткую информацию о файлах во временном хранилище:
Если же дополнительно указать опцию -p, вывод будет дополнен расширенным описанием изменений файлов:
Параметр stash.showPatch делает это поведением по умолчанию. Применить его глобально можно с помощью аналогичной команды:
Как и в предыдущем случае, включённый параметр можно отменить и тем самым вернуться к старому краткому выводу, — с помощью опции --stat:
Будьте аккуратны: опция --no-patch не приводит к ошибке, однако она не отменяет stash.showPatch, как можно было бы ожидать.
package.json
- name — название проекта
- version — версия проекта (см. версионирование)
- description — описание проекта (зачем нужен пакет?)
- keywords — ключевые слова (облегчает поиск в реестре npm)
- private — установка значения в true предотвращает случайную публикацию пакета в реестре npm
- main — основная точка входа для функционирования проекта
- repository — ссылка на репозиторий (один из вариантов)
- author — автор проекта (один из вариантов)
- contributors — участники проекта (люди, внесшие вклад в проект)
- dependencies — зависимости проекта (пакеты, без которых приложение не будет работать)
- devDependencies — зависимости для разработки (пакеты, без которых приложение будет работать)
- scripts — команды (выполняемые сценарии, задачи), предназначенные для автоматизации, например, команда «yarn dev» запустит скрипт «nodemon server.js»
Файлы «package-lock.json» и «yarn.lock» содержат более полную информацию об установленных пакетах, чем package.json, например, конкретные версии пакетов вместо диапазона допустимых версий.
Но и это ещё не всё!
Это только небольшая часть плюшек, которые появились в Git 2.7. Полный список изменений можно найти в заметках к релизу, а также в комментариях к коммитам в репозитории самого Git:
Автор оригинальной статьи — Тим Петтерсен, участвовал в разработке JIRA, FishEye/Crucible и Stash. С начала 2013 года он рассказывает о процессах разработки, git, непрерывной интеграции и поставке (continuous integration/deployment) и инструментах Atlassian для разработчиков, особенно о Bitbucket. Тим регулярно публикует заметки об этих и других вещах в Twitter под псевдонимом @kannonboy.
При разработке собственного проекта, рано или поздно, приходится задуматься о том, где хранить исходный код и как поддерживать работу с несколькими версиями. В случае работы на компанию, обычно это решается за вас и необходимо только поддерживать принятые правила. Есть несколько общеупотребимых систем контроля версий, и мы рассмотрим одну из самых популярных — это 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 и Github. Каждая приведенная выше команда имеет значительно больше ключей и соответственно возможностей. Постепенное их изучение даст вам возможность легко оберегать свои иходники и больше концентрироваться непосредственно на разработке.
Предлагаю вашему вниманию небольшую шпаргалку по основным командам bash, git, npm, yarn, package.json и semver.
Условные обозначения: [dir-name] — означает название директории, | — означает «или».
Рекомендую вводить каждую команду в терминале и внимательно изучать вывод, так вы быстро их запомните и определите, какие команды вам нужны, а какие нет.
Приношу извинения за возможные ошибки и опечатки. Буду рад любым замечаниям и предложениям.
Без дальнейших предисловий.
bash представляет собой инструмент командной строки, позволяющий выполнять некоторые распространенные действия.
Установка: в моем случае bash был установлен вместе с git.
Выход из терминала:
Путь к текущей директории:
Копирование, перемещение и удаление файла:
Вывод в терминал строки:
git представляет собой распределенную систему контроля версий, позволяющую контролировать процесс внесения изменений в проект.
Удаление файлов и директорий:
Просмотр состояния репозитория:
Просмотр разницы между коммитами:
Просмотр истории изменений:
Работа с ветками:
Разрешение конфликтов при слиянии:
Сохранение незакоммиченных изменений:
Автозавершение повторных конфликтов:
Пример алиасов (сокращений) для .gitconfig:
npm представляет собой пакетный менеджер, позволяющий устанавливать зависимости проекта.
npm устанавливается вместе с Node.js.
Также вместе с Node.js устанавливается npx, позволяющий запускать исполняемые файлы без установки: npx create-react-app my-app.
Список доступных команд:
Принудительная переустановка зависимостей:
Установка только продакшн-пакетов:
Добавление зависимости для разработки:
Глобальная установка/обновление/удаление пакета:
Определение устаревших пакетов:
Список установленных зависимостей:
Информация о пакете:
Запуск скрипта/выполнение команды:
Удаление дублирующихся пакетов:
Удаление посторонних пакетов:
Обнаружение уязвимостей (угроз безопасности):
Автоматическое исправление уязвимостей:
yarn, как и npm, представляет собой пакетный менеджер, позволяющий устанавливать зависимости проекта.
Команда «yarn dlx» позволяет запускать исполняемые файлы без установки: yarn dlx create-react-app my-app. Для этого yarn необходимо обновить до второй версии: yarn set version berry.
Список доступных команд:
Принудительная переустановка зависимостей:
Установка только продакшн-пакетов:
Добавление зависимости для разработки:
Глобальная установка/обновление/удаление пакета:
Список установленных зависимостей:
Информация о пакете:
Запуск скрипта/выполнение команды:
Ускорение git filter-branch и индикатор прогресса
git filter-branch — это универсальный инструмент для изменения истории репозитория. Поскольку каждый коммит имеет ссылки на родительские коммиты, а значит, транзитивно ссылается на все коммиты, являющиеся его предками, изменение одного коммита неизбежно влечет за собой изменение всех его потомков. Это, в свою очередь, означает, что операция даже элементарного изменения истории может занять какое-то время, если изменить нужно достаточно старый коммит.
В Git 2.7 появился изящный индикатор прогресса, который отображает предполагаемое время до окончания выполнения filter-branch:
Помимо этого, в случае если filter-branch не изменяет объекты в индексе или деревья, то индекс вообще не читается при выполнении команды, что значительно увеличивает её производительность. Опция --commit-filter на анимации выше изменяет только автора каждого коммита и не затрагивает ассоциированные с ними объекты деревьев. Изменение первых 1000 коммитов Bitbucket Server заняло всего 38 секунд при использовании Git 2.7.0, в то время как аналогичная операция с Git 2.6.0 потребовала 64 секунды, то есть прирост скорости составляет целых 40%. Тесты производительности, появившиеся в Git 2.7 вместе с этими улучшениями, показывают ещё более впечатляющее ускорение — до 60%.
7 Answers 7
It would appear that the ** syntax is supported by git as of version 1.8.2.1 according to the documentation.
A leading " ** " followed by a slash means match in all directories. For example, " **/foo " matches file or directory " foo " anywhere, the same as pattern " foo ". " **/foo/bar " matches file or directory " bar " anywhere that is directly under directory " foo ".
A trailing " /** " matches everything inside. For example, " abc/** " matches all files inside directory " abc ", relative to the location of the .gitignore file, with infinite depth.
A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, " a/**/b " matches " a/b ", " a/x/b ", " a/x/y/b " and so on.
Other consecutive asterisks are considered invalid.
xxx/** targets all the files and directories inside of xxx whereas xxx/ targets the xxx directory directly. This really only matters when negating patterns with ! as "It is not possible to re-include a file if a parent directory of that file is excluded.", so using xxx/* or xxx/** would be necessary in that case.
Never tried it, but git help ignore suggests that if you put a .gitignore with *.js in /public/static , it will do what you want.
Note: make sure to also check out Joeys' answer below: if you want to ignore files in a specific subdirectory, then a local .gitignore is the right solution (locality is good). However if you need the same pattern to apply to your whole repo, then the ** solution is better.
That's not necessary the best solution. Potentially people will need to dig through different .gitignore files to find why their file is being ignored. Some prefer having all this information in one .gitignore file stored at repo root directory.
@haren it's not the only solution - Joey's answer is certainly valid as well. Choose whatever works best for you. I'd argue that ignore rules local to a directory should be in that directory, and that global rules should be global. (Also, this answer is ancient and I don't think ** was supported at the time).
UPDATE: Take a look at @Joey's answer: Git now supports the ** syntax in patterns. Both approaches should work fine.
Patterns read from a .gitignore file in the same directory as the path, or in any parent directory, with patterns in the higher level files (up to the toplevel of the work tree) being overridden by those in lower level files down to the directory containing the file.
What this means is that the patterns in a .gitignore file in any given directory of your repo will affect that directory and all subdirectories.
The pattern you provided
isn't quite right, firstly because (as you correctly noted) the ** syntax is not used by Git. Also, the leading / anchors that pattern to the start of the pathname. (So, /public/static/*.js will match /public/static/foo.js but not /public/static/foo/bar.js .) Removing the leading / won't work either, matching paths like public/static/foo.js and foo/public/static/bar.js . EDIT: Just removing the leading slash won't work either — because the pattern still contains a slash, it is treated by Git as a plain, non-recursive shell glob (thanks @Joey Hoer for pointing this out).
As @ptyx suggested, what you need to do is create the file /public/static/.gitignore and include just this pattern:
There is no leading / , so it will match at any part of the path, and that pattern will only ever be applied to files in the /public/static directory and its subdirectories.
Всего через два месяца после версии 2.6 вышел Git 2.7 с новыми возможностями, исправлениями и улучшениями производительности. Что интересного он нам приготовил? Я расскажу о нескольких новинках, которые показались интересными команде Bitbucket.
1 ответ 1
Проблема может быть в том, что в папках, уровень которых выше папки проблемного файла (например, в корне, или в /one/ ), существуют файлы, удовлетворяющие шаблону, т.е. в данном случае, файлы с расширением txt . Таким образом, git add *.txt находит этот файл из корня или другого уровня, выше желаемого (однако он не изменён и не отражается в результатах команды git status ) и прекращает искать файлы в папках с большей вложенностью.
Таким образом, чтобы гарантированно добавить файлы из вложенных папок, придётся указать полный путь к этим папкам. Но в некоторых случаях может быть полезна комбинация вида */*.txt , которая найдёт файлы во вложенных папках (ограничится тем уровнем вложенности, где будут найдены первые файлы, удовлетворяющие шаблону).
В данном случае, после команды git add */*.txt проблемный файл будет добавлен:
Улучшенное отрицание в .gitignore
Файлы .gitignore позволяют исключить из репозитория некоторые файлы, находящиеся в рабочей копии, т.е. они не будут добавляться в индекс. Шаблоны поддерживают флаг отрицания с помощью префикса !, чтобы было возможно отменить игнорирование определённого файла. Например, при таких шаблонах git будет игнорировать все файлы с расширением .json, кроме cat.json:
Однако в Git 2.6 нельзя было применить отрицание к файлу, находящемуся в уже игнорируемой папке.
Начиная с Git 2.7, второй пример работает ровно так, как этого стоило ожидать: с помощью ! теперь можно отменить игнорирование файлов в папках, которые иначе были бы игнорированы.
Полноценный набор команд git worktree
Команда git worktree появилась в Git 2.5, она позволяет выгружать и одновременно работать со многими ветками репозитория в отдельных папках. Например, если нужно сделать срочную правку, но при этом не хочется трогать текущую рабочую копию, можно просто выгрузить нужную ветку в новую папку с помощью команды:
Git 2.7 добавляет команду git worktree list, которая выводит список рабочих копий репозитория и веток, ассоциированных с ними:
Улучшена поддержка многих рабочих копий командой git bisect. Ссылки, которые использовались bisect для «хороших» и «плохих» коммитов, переехали из .git/refs/bisect в .git/refs/worktrees/$worktree_name/refs/bisect, поэтому теперь стала возможной одновременная работа bisect в разных рабочих копиях репозитория.
Кроме того, начиная с Git 2.7 можно использовать git clone, указав в качестве аргумента такую отдельную рабочую копию, — при этом будет создан независимый git-репозиторий, а не ещё одна рабочая копия существующего.
Примечательно, что отдельные рабочие копии могут быть созданы не только для веток. Как и множество других команд, git worktree add можно вызвать с указателем на коммит, будь то его хеш или тег:
Всё ещё ищете ответ? Посмотрите другие вопросы с метками git или задайте свой вопрос.
Похожие
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Site design / logo © 2022 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2022.5.12.42104
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Версионирование
Каждый пакет имеет версию, состоящую из трех цифр (например, 1.0.0), где первая цифра — мажорная версия (major), вторая — минорная версия (minor), третья — патчевая версия (патч, patch). Выпуск новой версии называется релизом.
Увеличение каждой из этих цифр согласно правилам семантического версионирования (semver) означает следующее:
Есть некий проект с древовидной структурой папок, обслуживаемый git'ом. Я нахожусь в консоли на верхнем уровне проекта и у меня есть несколько файлов, которые были изменены, во вложенных папках. Я вижу эти измененные файлы по команде git status , например:
Подобных файлов может быть много и я хочу их добавить с помощью шаблонных имён. Например, добавить все csv файлы командой git add *.csv , а все txt файлы командой git add *.txt . Я выполняю эти две команды, однако в результате вижу, что в индекс добавились только файлы *.csv :
Почему не добавились файлы с расширением txt ?
@alexanderbarakin спасибо за советы, Александр. Не забывайте начинать предложения с заглавной буквы :)
@alexanderbarakin удобство не страдает. Вся нужная информация есть уже и в тексте. Картинки приведены для демонстрации различий между добавленными и недобавленными файлами.
Читайте также: