Сергей Кузнецов

Он перешёл на предпоследнюю ветку и не удаляя последнюю, закоммитился

что еще за "последние" и "предпоследние" ветки, какие-то новые понятия в git?

Как соединить коммиты и исправить ситуацию?

в ветке main сделать (на выбор):

• git reset --hard origin/main, тогда main станет соответстовать origin/main, но коммиты e32d4e8 и 690c2b9 пропадут, но не из истории, так что их можно будет подтянуть: git cherry-pick e32d4e8, git cherry-pick 690c2b9
  
• git reset --soft origin/main, посмотреть git status и сделать новые коммиты
  
• git rebase origin/main, тогда коммиты e32d4e8 и 690c2b9 начнут применяться заново, начиная с коммита 69805c1 (в ходе применения могут возникать конфликты, а так же у применяемых коммитов будет новый хэш)
  
• git rebase -i origin/main (интерактивный ребейз), почти то же самое, как предыдущее, но сначала откроется текстовый редактор (который в git указан как редактор по умолчанию) и в нем можно будет указать как именно делать ребейз, например можно будет не переность коммит 690c2b9 или изменить сообщение коммита
  

В настройках сетевой карты есть галочка "извещать о состоянии", или что-то похожее по смыслу. Вот её надо отключить.

Репозиторий проекта - это не что-то стандартное. Авторы вольны применять любые процессы и скрипты для сборки. Может когда-то какой-нибудь ЧатЖПТ и сможет "прочитать" ридми ЛЮБОГО проекта и проделать всё необходимое для его сборки, но пока что такой инструмент мало реалистичен. Если разработчик сам не настроил CI/CD в проекте, то никак без него это сейчас не сделать.

https://dev.to/katkelly/changing-your-repo-s-langu...

1. Создаёшь в репозитории файл ".gitattributes"
2. Перечисляет в нём все языки, которые не надо детектить:
*.css linguist-detectable=false
Можно не просто расширение указать, а конкретные файлы или путь, чтобы игнорировать все файлы в определённой папке.
3. Не забудь закоммитить и запушить изменения.

Ну и не забывай про gitignore - возможно, эти файлы вообще не должны быть в репозитории, если они получаются в результате работы scss

Покажи результат выполнения команды

ssh -T git@github.com
и
git remote -v

Через ssh-keygen создал пару ключей.

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

Я советую забыть для начала о ChatGPT и прочитать пару постов (или посомотреть видео) "мой первый workflow".
Если коротко, Self-Hosted Runner обычно не нужен.
Чтобы запуститься на линукс, пишем

runs-on: ubuntu-latest

Фича ветки делаем только от актуального main.
Для проверки мержим фича-ветку в dev, но не удаляем.
Когда одна или несколько фичей проверены и готовы, то делаем от main релизную ветку и мержим туда все готовые фичи, прогоняем тесты и если всё ок, то мержим релизную вету в main.
Ну и полезно мержить main в фича ветки, когда main обновился.

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

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

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

В каждую директорию keys добавить свой гитигнор следующего содержания

*
!.gitignore
!*.pub

Либо попробовать в корневом

**/keys/*
!**/keys/*.pub

Первый вариант стопроцентный. Второй - хз.

но и в целом законность использования одноранговой сети без каких-либо средств защиты, например того же доступа по учеткам из Active Directory

Так а откуда Active Directory в одноранговой сети?
Ну и собственно в Windows Home нет поддержки Active Directory.

И с чего это Active Directory это средства защиты? Это средство централизированного управления.

Никогда не используй сжатие с потерями jpeg для таких целей. Используй PNG.

По сути вопроса:
git config --show-origin core.ignoreCase
Покажет, где установлено. Я во всех репах после инициализации или клонирования даю:
git config --unset core.ignoreCase
По умолчанию Git различает регистр, но шаблон конфига для Windows выставляет core.ignoreCase = true.

А вот старые коммиты останутся как есть. Если вам важен регистр, нужно взять git-filter-repo и перебить репу. Примерно так:

git filter-repo --force --prune-empty always --prune-degenerate always --path-rename hello.cs:Hello.cs

Вместо одиночного или нескольких --path-rename можно написать целую простыню переименований в отдельном файле. Поддерживаются регулярки. Читайте доку, короче.

Оно перебьет хеши измененных коммитов, то есть репу придется загружать на сервер/GitHub заново, но тут уже ничего не попишешь: или один раз исправить, или продолжать мучиться.