Игнорирование файлов и каталогов в git (.gitignore)

Файл отладки .gitignore

Иногда бывает сложно определить, почему конкретный файл игнорируется, особенно когда вы используете несколько файлов .gitignore или сложные шаблоны. Вот тут-то и пригодится команда git check-ignore с опцией -v, которая говорит git отображать подробности о соответствующем шаблоне.

Например, чтобы проверить, почему файл www/yarn.lock игнорируется, вы должны выполнить:

git check-ignore -v www/yarn.lock

Выходные данные показывают путь к файлу gitignore, номер совпадающей строки и фактический шаблон.

www/.gitignore:31:/yarn.lock	www/yarn.lock

Команда также принимает более одного имени файла в качестве аргументов, и файл не обязательно должен существовать в вашем рабочем дереве.

.gitignore Шаблоны

— это простой текстовый файл, в каждой строке которого содержится шаблон, который файлы или каталоги следует игнорировать.

Комментарии

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

Слэш

Символ косой черты ( ) представляет собой разделитель каталогов. черта в начале шаблона относится к каталогу, в котором находится .

Если шаблон начинается с косой черты, он соответствует файлам и каталогам только в корне репозитория.

Если шаблон не начинается с косой черты, он соответствует файлам и каталогам в любом каталоге или подкаталоге.

Если шаблон заканчивается косой чертой, он соответствует только каталогам. Когда каталог игнорируется, все его файлы и подкаталоги также игнорируются.

Самый простой шаблон — это буквальное имя файла без каких-либо специальных символов.

Шаблон	Примеры совпадений

Подстановочные символы

— символ звездочки соответствует нулю или более символам.

Шаблон	Примеры совпадений

— Два соседних символа звездочки соответствуют любому файлу или нулю или более каталогам. Если за ним следует косая черта ( ), он соответствует только каталогам.

Шаблон	Примеры совпадений
	Соответствует чему-либо в каталоге .

— Знак вопроса соответствует любому одиночному символу.

Шаблон	Примеры совпадений

Квадратных скобок

— соответствует любому из символов, заключенных в квадратные скобки. Когда два символа разделены дефисом это обозначает диапазон символов. Диапазон включает все символы, которые находятся между этими двумя символами. Диапазоны могут быть буквенными или числовыми.

Если первый символ после — восклицательный знак ( ), То шаблон соответствует любому символу, кроме символов из указанного набора.

Шаблон	Примеры совпадений

Отрицательные паттерны

Шаблон, который начинается с восклицательного знака ( ), Отменяет (повторно включает) любой файл, который игнорируется предыдущим шаблоном. Исключением из этого правила является повторное включение файла, если его родительский каталог исключен.

Шаблон	Примеры совпадений
	или не будут проигнорированы

Основные команды в Git

git init

Чтобы проинициализировать (создать) пустой Git репозиторий введите команду:

git init

Будет создана папка . Репозиторий — это скрытая папка, в которой работает Git.

По умолчанию команда создает ветку .

git clone

git clone 

Получаем копию существующего репозитория, клонировав удаленный, например, с gitHub.

Предварительно необходимо выполнить команду .

mkdir epicgame & cd epicgame
git init
git clone 

git clone  

Эта команда аналогично предыдущей, но все файлы перемещаются в папку

git status

Команда, показывающая статус репозитория, чтобы увидеть в каком состоянии находится наш проект:

git status

Получаем сведения в более компактной форме при помощи флага ():

git status -s
git status --short

• ?? — новые неотслеживаемые файлы
• A — файлы добавлены в область предварительной подготовки
• M — модифицированные

git add (Отслеживание новых файлов)

Данная команда может работать как «Добавление файлов к проекту» (добавляем в индекс).

Чтобы сообщить git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью команды:

git add 

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

Флаг позволяет принудительно добавить что-то в индекс, даже несмотря на то что это что-то может находиться в .

git add --force folder/text.txt

git add (Индексация изменённых файлов)

Также данная команда может работать как «Добавление содержимого к следующему коммиту».

Давайте модифицируем файл, уже находящийся под версионным контролем. Чтобы проиндексировать его, необходимо выполнить команду:

git add 

git —all или git -a

Флаг или укажет на то, что необходимо взять все изменения из рабочей директории, внести их в индекс () и тут же закоммитить в репозиторий. Но игнорирует файлы, который не отслеживаются git (untracked file).

git commit -a -m "comment"
git commit -am "comment"

git reset (Отмена индексирования)

Индексируем:

git add *

Примечательно, что команда покажет, как отменить индексирование:

Changes to be committed:
(use "git reset HEAD ..." to unstage)

Отменим индексирование:

git reset HEAD *

Или сбросим изменения в индексе для каталога (служебный каталог webstorm)

git reset HEAD .idea

git commit

Фиксируем изменения:

git commit -m "my comment"

Флаг позволяет задать сообщение фиксации.

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

Флаг позволяет автоматически индексировать все отслеживаемые файлы перед их фиксацией.

git commit -a -m "my comment"

git rm

Команды , которая не только удалит файлы с диска, но и добавит сведения об их удалении в Git.

git rm '*.txt'

Чтобы удалить директорию:

git rm -r src

Если вы проиндексировали файл, то следует воспользоваться параметром , который инициирует принудительное удаление ( файл будет удален как из рабочей директории, так и из индекса).

git rm -f index.html

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

git rm --cached 

git amend (Изменение последнего коммита)

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

git add .

Далее закоммитить изменения с параметром :

git commit --amend

Эта команда берет индексированный файлы и включает в коммит всю обнаруженную там информацию.

Чтобы изменить название коммита выполните:

git commit --amend -m "new name commit"

git checkout (Отмена изменение в файле)

С подсказкой опять поможет команда :

use "git checkout -- ..." to discard changes in working directory

Отметьте, что все что после воспринимается как путь.

Итак, файлы могут быть возвращены в состояние последнего коммита с помощью команды:

git checkout -- 

git checkout (Получаем предыдущие версии файлов, не трогая остальные)

Допустим нам нужно вернуть версию файла, которая была два коммита назад. При этом нам требуется откатить лишь один файл.

Восстановим файл на момент конкретного коммита ():

git checkout 0b335 index.html

Или откатим версию файла до состояния из текущего коммита (откатим изменения, которые нас не устраивают):

git checkout HEAD index.html

Что аналогично:

git checkout index.html

git clone

При клонировании автоматически добавляется удаленный репозиторий с именем .

Кроме того при клонировании git автоматически настраивает локальную ветку на слежение за удаленной веткой .

2 ответа

Лучший ответ

Предполагая, что PR означает Pull Request, это именно то, что вы должны увидеть — все коммиты с момента последнего клонирования хранилища. Как правило, рекомендуется сохранять эти коммиты, так как они расскажут все, что и как изменилось.

Однако, если это случай «чрезмерной фиксации» в результате фиксации всякий раз, когда что-то изменилось, а не когда задача или проблема были решены, то вы, безусловно, можете раздавить / перебазировать ваши коммиты в одну. Подробности смотрите ниже

• SO: Есть ли способ раздавить несколько коммитов не в интерактивном режиме?
• SO: Сквош мой последний X коммитов вместе с помощью Git
• Git: Squash ваши последние коммиты в один

-1

Community
23 Май 2017 в 12:24

Ваш рабочий процесс не выглядит правильным. Есть два варианта, как вы можете внести свой вклад:

1. У вас есть разрешение на запись в репозиторий верхнего уровня. Затем вам нужно просто клонировать вышестоящий репозиторий, извлечь новую ветку и зафиксировать ваши изменения там. Когда вы закончите, вы отправляете свою новую ветку в восходящий fix / my-fix` и открываете PR внутри этого репо.

2. У вас нет прав на запись, то есть вы не можете выдвигать какие-либо ветви в репозиторий верхнего уровня. Сначала вы должны создать приватную ветвь хранилища, а затем клонировать свою вилку на свой компьютер. Также теперь вы должны создать новую ветку для вашего исправления или добавления функции. Получив это, вы отправляете ветку в личный репозиторий . Эта часть немного сбивает с толку, но Github заставит ее работать. После этого вы можете открыть PR в исходном репозитории в своем апстриме. Для этого перейдите к своему профилю GitHub и вашему репозиторию и начните PR с вашей новой веткой. Вы должны быть в состоянии выбрать основной канал в качестве цели слияния для вашей новой ветви.

Если вы все еще видите все старые коммиты, когда открываете новый PR, тогда ваши ветви разошлись, кто-то принудительно подтолкнул изменения к мастеру или что-то в этом роде. Вы можете проверить общего предка двух ветвей и с помощью . Затем вы можете использовать интерактивную ребазу , чтобы поместить вашу ветку поверх другой и отбросить все ненужные коммиты.

1

Potaito
9 Янв 2019 в 16:13

Просмотр истории коммитов

Не все коммиты будете делать вы, какие-то будут делать ваши коллеги по команде, поэтому вам может понадобиться изучить историю коммитов. Одним из основных и наиболее мощных инструментов для этого является команда .

Помимо автора и даты, у каждого комита есть идентификатор, который называется hash. Пример: 2934ee19f4d4ca37ff9bea9dc8208ef5362d789e. Необязательно использовать такую длинную запись, git поймет и по первым 5 символам, какой hash вам нужен.

Команда имеет очень большое количество опций для поиска коммитов по разным критериям.

Одним из самых полезных аргументов является или , который показывает разницу, внесенную в каждый коммит. Можно ограничить количество записей в выводе команды, используя параметр :

Общее

Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит)

Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс (), потом «сохраняем» ()

Любой файл в директории существующего репозитория может находиться или не находиться под версионным контролем (отслеживаемые и неотслеживаемые).

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Ключ к пониманию

Ключ к пониманию концепции git — знание о «трех деревьях»:

• Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
• Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
• Директория — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.

У всех коммитов (кроме самого первого) есть один или более родительских коммитов, поскольку коммиты хранят изменения от предыдущих состояний.

Простейший цикл работ

• Редактирование, добавление, удаление файлов (собственно, работа).
• Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
• Коммит (фиксация изменений).
• Возврат к шагу 1 или отход ко сну.

Указатели

• — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
• — указатель на коммит, с которого вы только что переместили (командой , например).
• Ветка (, etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
• Теги — простые указатели на коммиты. Не перемещаются.

Перед началом работы нужно выполнить некоторые настройки:

Если вы в Windows:

Длинный вывод в консоли: Vim

Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w.

# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти
```bash
# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти

# Ввод в командном режиме
:q!             — выйти без сохранения
:wq             — сохранить файл и выйти
:w filename.txt — сохранить файл как filename.txt

Основные сообщения в консоли:

• checkout — выгрузка;
• Untracked file — не отслеживаемый файл; git видит файл, но он отсутствует в предыдущем снимке состояний (коммит); подобный подход гарантирует, что в репозитории не окажется случайных файлов. Такие файла необходимо добавить в индекс командой .
• Changes to be committed — все проиндексированные файл идут под этим заголовком.
• Changes not staged for commit — отслеживаемый файл изменен, но пока не проиндексирован.
• Changes but not updated — после удаления файла; измененные, но не проиндексированные
• fast forward (перемотка) — возникает при слиянии веток, указывает на то, что изменений требующих объединений нет; другими словами объединяется ветка-родитель и ветка-потомок
• unmerged (необъединенное) — обычно возникает при конфликтах
• master d16556e [origin/master: ahead 1] comment — — наличие 1-го локально коммита, который пока не отправлен на сервер; — на сервере есть 1 коммит, который пока не слит.
• pull request — запрос на включение.

Использование

Теперь можно вообще забыть про существование и просто пользоваться
Git как обычно, а будет выполнять все описанные проверки, изредка
беспокоя вас прерванными операциями, если будут найдены какие-нибудь проблемы.
Давайте снова попробуем закоммитить тот сломанный файл с пробелами и кавычками:

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

На YAML программировать намного приятнее, чем на ! Да, честно говоря,
практически на чём угодно писать приятнее, чем на .

Альтернативы

Мне проще всего использовать инструменты, написанные на знакомом мне языке,
но вообще далеко не уникальный инструмент и имеет множество
альтернатив. Если вы пишете не на Python, то может быть вам будут ближе другие
инструменты, хотя все они имеют примерно схожий функционал:

• на JS;
• на Go;
• на Ruby.

Возможно, вы также найдете для себя что-то полезное на странице
“Awesome Git hooks”.

Заключение

Я всегда стараюсь использовать Git-хуки для запуска всех быстрых проверок.
Это не дает мне забывать о проверках, и позволяет быстрее получать обратную связь.

Представьте ситуацию, когда сидишь и ждёшь результатов проверок от CI,
которые могут быть достаточно долгими
(на проекте, где я сейчас работаю, тесты выполняются 8-10 минут),
видишь красный крестик, идёшь посмотреть, что же там сломалось,
а там всё почти отлично — тесты прошли, но только нашёл лишний пробел.
Чинишь лишний пробел и снова ждёшь 10 минут, чтобы получить свою зелёную галочку.
Дак вот хуки спасают от таких ситуаций, потому что все тривиальные проблемы
обнаруживаются за несколько секунд локально на моей машине и
никогда не попадают в историю Git.

Настоятельно рекомендую пользоваться Git-хуками. Это позволит вам не тратить
время на ерунду, и в итоге быть более эффективным и довольным разработчиком.

Примеры из поста можно найти
здесь.

rebase

Команда своего рода швейцарский нож для истории в git — с ее помощью можно переписывать историю — объединять, редактировать, менять местами коммиты. Но самое главное применение — это перенос или перебазирование веток.

Перенос веток

Допустим, у нас есть две ветки и ; ветка ушла вперед и нам нужно перенести коммиты из в ветку , для этого мы можем сделать:

    git rebase master

И ветка будет начинаться с более нового состояния . См. скрин rebase_01

Как это работает: все коммиты из ветки (также как это делает cherry-pick) переносятся в ветку .

При переносе веток возможны конфликты, в этом случае перенос (rebase) будет остановлен на том коммите, в котором возник конфликт — поправьте конфликт (зафиксируйте изменения) и выполните команду:

    git rebase --continue

Отказ от переноса

Чтобы отказаться от переноса (например, ваш rebase остановился на конфликте) выполните команду:

    git rebase --abort

Чтобы пропустить коммит при переносе, например, rebase остановился на конфликте, вы можете выполнить команду:

    git rebase --skip

Отмена rebase

Отмена rebase после того как rebase завершился.

    git reset --hard ORIG_HEAD

Или (что более надежно).

    git reflog feature

Глобальный .gitignore

Git также позволяет вам создать глобальный файл , в котором вы можете определить правила игнорирования для каждого Git-репозитория вашей локальной системы.

Файл может называться по вашему усмотрению и храниться в любом месте. Наиболее распространенным местом хранения этого файла является домашний каталог. Вам придется вручную создать файл и настроить Git для его использования.

Например, чтобы установить в качестве глобального файла игнорирования Git, выполните следующие действия:

1. Создайте файл:

2. Добавьте этот файл в Git-конфигурацию:

3. Откройте файл в текстовом редакторе и добавьте в него свои правила.

Глобальные правила особенно полезны при игнорировании определенных файлов, которые вы никогда не захотите фиксировать, таких как файлы с конфиденциальной информацией или скомпилированные исполняемые файлы.

Что если файлы из gitignore уже добавлены в репозиторий

Обратите внимание, что если файлы уже добавлены в git репозиторий, то добавление их в не удалит эти файлы. Изменения в них будут продолжать отслеживаться и входить в коммиты, несмотря на то, что они есть в

Нам придется вручную их удалить из репозитория.

Очень удобная команда bash, которая удалит из git репозитория те файлы, которые содержатся в файлах :

git rm --cached `git ls-files -i --exclude-from=.gitignore`

То же самое для Powershell

foreach ($i in iex 'git ls-files -i --exclude-from=.gitignore') { git rm --cached $i }

При выполнении этой команды, файлы останутся у вас на диске, однако из репозитория они будут удалены.

Либо можно удалять файлы вручную, таким образом:

git rm --cached path/to/file

Либо если нам нужно удалить целую директорию из git, то воспользуемся следующей командой:

git rm  -r --cached path/to/directory

Либо так мы могли бы удалить все файлы с расширением .log в папке log:

git rm --cached log/\*.log

Параметр означает, что файлы будут удалены только из раздела «проиндексированных файлов».
На диске (рабочем каталоге) они останутся нетронутыми.

Задача №3 — Откат изменений

Легенда

Команда из NeuroStartUp начала работать над сайтом в Git, но случилось непредвиденное: один из разработчиков допустил ряд ошибок и залил всё вместе с ошибками в репозиторий на GitHub. Вам нужно отменить его последний коммит и исправить ситуацию.

Задача

Примечание*: поскольку вы использовали операцию в первом пункте, то в вашем репозитории уже существует . При попытке добавления второго такого, будет ошибка. Поэтому вместо пишем и push тоже делаем в .
Посмотреть все связи локального репозитория можно командой .

В качестве результата пришлите проверяющему ссылку на ваш репозиторий на GitHub.

Пожалуйста, не прикладывайте никакие файлы

Все задачи обязательны к выполнению. Присылать на проверку можно только сразу все три задачи.

Любые вопросы по решению задач задавайте в чате учебной группы.

Просмотр истории и старых версий

git log

Для просмотра изменений (истории коммитов) используется команда

git log

, которая покажет список последних коммитов и их хеши SHA1. Первыми показываются последние коммиты.

Или можно использовать

git log --oneline

Или для конкретной ветки

git log master --oneline

У множество возможностей, например, мы можем выводить историю в более удобном формате:

git log --pretty=format:"%h - %an, %ar : %s"

• – короткий код самого коммита;
• – автор;
• – когда был сделан;
• — комментарий;
• — Хеш-код коммита;

Ограничивать коммиты по времени:

git log --since=2.weeks

Показывать разницу, внесенную каждым коммитом:

git log -p -2

• показывает разницу, внесенную каждым коммитом. ограничивает выводимый результат последними 2 записями.
• используется для получения краткой статистики по каждому коммиту.
• добавляет графику с историей ветвлений и слияний

git log ..

git log name_branch..origin/master

сужит фильтром для команды и означает, что отображать следует только те коммиты из , которых нет в .

git log — выводим нужные коммиты

Зададим какие именно коммиты нужно выводить. по умолчанию выводит коммиты достижимые из . Но можно задать коммиты, например, по хэшу, ветке, и тогда будет выведены коммиты достижимые по хэшу, ветке.

git log master

git log 34assd

Из двух веток:

git log master feature --graph

Выведем коммиты достижимые из всех ссылок:

git log --all --graph

Просмотр коммитов (кроме)

Например, нам нужно просмотреть коммиты, которые произошли в ветке , которые, в свою очередь, произошли с момента ее расхождения от (то есть КРОМЕ коммитов на ветке master):

git log feature ^master

аналогично:

git log master..feature

Просмотр коммитов (И различий) по файлу

Выведем коммиты, в которых менялся файл :

git log index.html

Выведем конкретные различия, в которых менялся файл :

git log -p index.html

   Флаг-фильтр —grep

Поиск всех коммитов в описании которых есть слово :

git log --grep word

сделаем регистронезависимым:

git log --grep word -i

   Флаг-фильтр -G

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

Найдем вызов функции:

git log -GdoAny() -p

Найдем объявление функции:

git log -G'function doAny\(' -p

Не забывайте, что это регулярное выражение.

Флаг позволяет увидеть непосредственно изменения.

   Флаг-фильтр -L

Выводи все коммиты с n-й по n-ю строку, например, выведем с 3-й по 7-ю строку:

git log -L 3,7:index.html

Или найдем фрагмент кода по регулярному выражению:

git log -L '/<head>/','/<\/head>/':index.html

Возможность очень полезная, так как позволяет отследить изменения любого блока кода в файле.

Выводы

Несмотря на то, что файл и возможно удалить после случайного коммита, этого следует избегать. Есть несколько простых вещей которые стоит избегать, и наоборот использовать:

• Использовать программы с графическим интерфейсом для работы git. Они наглядно показывают какие файлы будут добавлены в коммит. Во всех средах разработки как правило есть либо дополнения, либо встроенные средства для работы с git которые помогают избежать таких ошибок. Если среда разработки которую вы используете не имеет средств работы с git, то есть графические интерефейсы. Я когда-то писал небольшой обзор графических интерфейсов для git;
• Избегать таких опасных команд как , и . Вместо них добавлять отдельные файлы с ;
• Использовать чтобы интерактивно просматривать и добавлять файлы;
• Перед добавлением файлов внимательно просматривать какие файлы были изменены и могут попасть в коммит .

Полезные ссылки: