Комментарии 15
имя и почта, а еще прописываю условные настройки ссш ключей, почты и тп под проекты, где я в репозиториях гость
core.excludesfile: глобальный файл .gitignore - шикарно, не знал
не знаю, чего шикарного.. настройки игнорируемых файлов должны быть привязаны к проекту, а не к компьютеру. иначе какая-то каша получается.
Про многие типы файлов это дискуссионный и локальный вопрос, но есть и такие, которым реально место в .gitignore в 100% случаев. Пример - папка __pycache__, которая должна быть обычной скрытой папкой с артефактами, но её создатели питона не занеймили скрытой и по умолчанию гит в неё заглядывает
При чем тут настройки проектов и приколы ОС в части например .DS_Store ?
при том, что git - это, чаще всего, про коллективную разработку. и если в проекте решено игнорировать, упомянутые вами .DS_Store, то они должны быть проигнорированы всеми участниками разработки.
чем проще онбординг в проект, тем легче работается.
а вот про онбординг и коллективную работу - убедили.
сказывается, что я на каждый чих собственных петов создаю гит и как правило веду их один.
Пока это касается файлов связанных с проектом (полагаю, пример с __pycache__ выше из этой серии), т.е. таких, которые могут создаваться у всех разработчиков этого проекта - Вы правы, это должно быть в gitignore проекта.
Но вот что касается файлов, которые создают конкретные OS/IDE/редактор/etc. - эти файлы специфичны для окружения (и его настройки!) конкретного разработчика, поэтому они во-первых должны исключаться не только из этого проекта а из всех, и во-вторых только этот разработчик знает своё окружение и какой именно мусор оно создаёт, поэтому исключать их нужно в глобальном ignore-конфиге этого разработчика. Попытаться засунуть все возможные варианты таких файлов для всех возможных OS/IDE/etc. в gitignore проекта, конечно, можно. Но это дурная идея: во-первых это раздувает gitignore, во-вторых это дублируется в каждом проекте, в-третьих всегда найдутся оригиналы с нестандартными OS/IDE либо их нестандартными настройками из-за которых мусора в и работы по поддержке всей этой толпы gitignore в каждом проекте станет ещё больше.
Например я люблю в директории проекта держать свою директорию со всяким для текущей работы. Назовем ее local. А никто кроме меня так не делает или называет иначе. Это мелочь, но на одну строку в .gitignore будет меньше. Плюс может все пользуются условным инструментом от JetBrains, а приходит кто-то в проект кто хочет использовать неовим с подгрузкой конфигов под проект. И конфиги держит в той же директории. Также такую экзотику можно не тащить в общий гитигнор.
Конфигурация git у меня, можно сказать, минимальная.
Нет, это у меня конфигурация минимальная:
[core]
autocrlf = true
excludesfile = D:\\dev\\gitignore_globals.txt
[user]
name = delphinpro
email = delphinpro@yandex.ru
Вот бы была опция `git push --force` запретить и навязать вместо него `git push --force-with-lease --force-if-includes`, да документация чуть более подробно это раскрывающая, для любителей ребейзить.
Кто попривык к JB, можно вместо meld использовать дифф от продуктов JB, но там есть беда с меняющимися при смене версий путями. Не знаю зачем JB так усложнили жизнь себе и пользователям в этом плане.
[diff]
tool = vimdiff
guitool = rider
[difftool "rider"]
cmd = \"c:/Program Files/JetBrains/JetBrains Rider 2022.1/bin/rider64.exe\" diff \"$LOCAL\" \"$REMOTE\"
[merge]
tool = vimdiff
guitool = rider
[mergetool "rider"]
cmd = \"c:/Program Files/JetBrains/JetBrains Rider 2022.1/bin/rider64.exe\" merge \"$LOCAL\" \"$REMOTE\" \"$BASE\" \"$MERGED\"
trustExitCode = trueНу и кому хочется вообще лютых приключений - нынче можно коммиты подписывать SSH-ключом вместо GPG, а сам приватный SSH-ключ прогружать в агента, например, из KeePassXC по необходимости
Я для мерджей использую beyondcompare.
Зря я не взял этот материал :)
Популярные конфигурационные опции для работы с git