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

Не пили сук, на котором сидишь ©
Нельзя удалить ветку, которая в данный момент распакована в рабочем каталоге. Перед удалением ветки всегда переключите рабочий каталог на другую ветку.

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

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

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

При выводе названий файлов (команды типа state, ls-files, diff и т. п.) символы с кодом больше 0x80 Git заменяет восьмеричными кодами (например, \320\272 для символа «к»).

Начиная с версии 1.5.3 это поведение можно изменить с помощью конфигурационного параметра core.quotepath (принимает значения true/false или on/off).

Для отключения такого поведения выполните:
git config --global core.quotepath false

Источник

С какой ветки обновляет git pull?

Если вы не указали это в параметрах команды, то с той ветки определенного ВНЕШНЕГО репозитория, с которой вы ранее связали свою ветку, когда первый раз делали push с ключом -u (--set-upstream). Если связывание не было сделано, то простой git pull выдаст ошибку, так как не будет знать откуда обновляться.

я создал текстовый файл в master и хочу, чтобы он появился в моей ветке

Это делается через слияние: git merge master
И внешний репозиторий тут вам для этого не нужен.

Чтобы файл удалился из проекта, его нужно удалить из репозитория. Добавление в игнор ничего не удалит. Игнор лишь затруднит добавление файла в проект, если он ранее ещё не был добавлен. Если файл уже в репозитории, то его изменения будут отслеживаться до тех пор, пока вы его не удалите. Игнор не удалит файл и не сделает его невидимым.

Вопрос не в том, есть ли необходимость, а в том, в каких именно ситуациях следует использовать LFS.

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

передача файлов всё равно занимает одинаковое время

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

Git посчитает чуть меньше SHA1-хэшей

Почему вы так решили. Хэши в любом случае считаются все.

Попробуйте Sincthing

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

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

Но можно склеить принудительно:

# Сохранить адрес шаблона в переменную template 
git remote add template https://github.com/OWNER/TEMPLATE.git
# Скачать все обновления
git fetch template
# Попробовать сделать слияние ветки BRANCH-NAME шаблона с нашей текущей веткой
git merge --allow-unrelated-histories template/BRANCH-NAME

Опция --allow-unrelated-histories нужна, так как истории веток никак не связаны.

Вот правильный .gitignore

/*
!/test
!.gitignore

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

Прямым текстом написано

You are not allowed to force push code to a protected branch on this project

— у вас нет прав пересоздавать защищенные ветки.

С какой целью вы пытаетесь затереть другой репозиторий, вместо отправки в новый ПУСТОЙ проект?

Git и не удаляет ваши локальные правки. Если вы что-то изменили в рабочем каталоге и не собираетесь это коммитить, то оно и останется в таком состоянии даже после pull. Чаще наоборот спрашивают — почему pull не обновляет такие файлы.

Но всё равно лучше создать отдельный dev-конфиг — так надежнее.

Credential Manager забыли установить.

Рабочий каталог удаляйте таким-же способом.

cd .. # разумеется надо выйти из него
rm -r "название каталога"

И избегайте статей с названием «Git за полчаса» — это развод.
Вбивание непонятных команд в терминал это не обучение.
Git простой, но лучше потратить неделю чтобы понять азы и потренироваться.

В 2023 году рекомендованным методом является использование пакета filter-repo
Задача решается буквально одной командой

# Клонируем репо в соседний каталог
git clone --no-local . "../repo2" # тут будет новый репозиторий
# Перейдем в новый репо 
cd ../repo2 
# Оставим в проекте только содержимое подкаталога folder2, 
# сделав его новым корнем проекта
git filter-repo --subdirectory-filter "folder2/"

В любой непонятной ситуации смотрите git status — там будут все подсказки.

Серый цвет у вас скорее всего означает что эти объекты подпадают под игнор.
Желательно вывести их из игнора, иначе придется индексировать принудительно каждый файл с опцией force
И не забывайте, что используемый вами ключ --all не будет добавлять в репо новые файлы, обработаются только уже существующие но измененные файлы.

Вы же не на пустом месте ветку создали? В момент создания ветки «в неё» сразу попадают все предыдущие коммиты вниз по истории дерева коммитов. И после отправки, в ветке внешнего репозитория появится ровно столько коммитов, сколько было в локальном.

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