rPman

Идеологически git это про 'полную фиксацию изменений удаленно', скорее всего ваша задача (не то что описали а что решаете) - это создание своей ветки, работа в ней, с периодичекими объединениями изменений с master.

Я конечно могу придумать конструкцию, когда у вас 2 git репозитария, в который сливаются одни и те же файлы (симлинками на каталоги например), и вы попеременно применяете изменения в одном git но откатываете в другом, но это извращение, а так же из-за использования симлинков можно получить неожиданные ошибки, например когда приложение (visdual studio) неверно отслеживает изменения в каталогах.

p.s. у меня очень похожая конструкция была в eclipse проекте - там был солюшен из десятка проектов, каждый из которых должен был собираться как в консоли так и в ide для поддержки отладки, и структурно в файлах проекта были различия для одновременной поддержки этого, поэтому я собирал в ide симлинками и средствами самой ide проект из файлов и каталогов в другом месте, и оба они были в своих git (изменения, вносимые для работы в ide и отладки было вредно отправлять в центральный git).

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

Установи пакет git-lfs для своей ОС

Первый же результат на запрос инструкция по размещению github.io

Обратите внимание, что после загрузки проекта файл index.html должен находиться в корневой директории проекта:

само собой лучше читать оригинальную документацию но тут тебе по русски

Мое мнение - абсолютно бесполезен (из-за особенностей реализации и избытка функционала).

Главная фича git и других систем контроля изменений - это контроль за изменениями, возможность быстро откатиться к нужной версии, мержить версии, переносить изменения из одной ветки в другую и т.п. и все заточено на работу с текстом. большие файлы - это про бинарные или не редактируемые данные. Даже sql дампы таким образом адекватно не будут обработаны (пример - добавлена колонка)

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

git-lfs работает очень не эффективно, банальный git clone репозитарием из 20-гигабайтовых файлов требует сравнимый объем оперативной памяти, потому что там на любой файл идет diff/patch, что бессмысленно для бинарных файлов в подавляющем большинстве случаев.

Попробуй переименовать файл
git mv -f hello.cs Hello.cs
если он не будет давать это сделать на твоем текущем репозитарии, переименуй файл сначала обычными средствами файловой системы в hello.cs а потом с помощью git-mv

так измени конфиг той же командой

git config --global user.name XXX
git config --global user.email YYY
# так же убери --global если настройки локальны для репозитария

а еще конфигурация репозитария хранится в текстовом виде в .git/config просто отредактируй его

Не пользоваться google drive

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

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

Настрой пути сохранения сгенерированных css файлов на вне git репозитария, например второй, создав его специально для production ready файлов. Т.е. именно он и должен использоваться для переноса итоговых файлов в продакшн. либо заведи специальный подкаталог внутри git, добавив его в .gitignore, а саму инсталляцию в продакшн проводи другими способами.

sass style.scss:../prod/style.css

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

у вас windows и может быть установлено несоклько git? которые берут настройки из разных каталогов (например mingw версия и cygwin), случайно с jetbrains не ставится свой?

а в файл лог сохранить религия не позволяет?

по сути вопроса, перенаправь вывод в tail и укажи ключ -n N, в результате получишь последние N комитов

git log --pretty=oneline | tail -n 1