Сергей Соловьев

1. Гит в истории целые файлы, уже измененные, но сжатые (изменения хранит SVN, но у него другая модель работы)
2. Сравнение файлов происходит через сравнение хэша файла. История изменений хранится в виде графа, поэтому переключение - это по сути: 1. Найти общего предка 2. Откатиться до этого предка 3. Применить изменения до новой ветки. Дополнительно, если у тебя есть незакоммиченные текущие изменения, то гит тебе об этом скажет
3. Скачивается вся история изменений из удаленного репозитория и потом HEAD выставляется на ветку, которую клонировал (в основном это main/master)

Почитай как работает git

UPD: спасибо Saboteur за важное замечание

1. git merge feature --squash
2. git commit

Проблему решает --squash флаг при merge, только останется закоммитить это дело

Для пет проекта достаточно 2 веток - master и dev:
- master - работающий код, красивый, причесаный
- dev - в нем ведется вся работа

Нет смысла упарываться во всякие git flow, github flow и еже с ними. Над проектом работаешь ТОЛЬКО ТЫ, а значит делать надо как тебе удобнее.
Думать об этом надо только если над одним проектом работает больше 1 человека.

P.S. можно и одной веткой обойтись, но так удобнее откатываться и точно знаешь, что рабочий код не затронется

Используй -f ключ:
git add -f states/project1/keys/pk1.pub

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

в самом /www/sitefolder создать .gitignore в котором будет * (только астериск)
Тогда никакие файлы из этой и ниже лежащих не будут отслеживаться, но гитом можно будет пользоваться

git rm --cached .env