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

С какой ветки обновляет 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 не будет добавлять в репо новые файлы, обработаются только уже существующие но измененные файлы.

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

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

Неважно, что вы делали, гит перед каждым изменением записывает хэш указателя текущей ветки в специальный журнал — reflog. Соответственно вы можете этот журнал посмотреть командой git reflog
А можно просто сослаться на порядковый номер в журнале и откатить текущую ветку на два шага назад:
git reset --hard HEAD@{2}
Как-то как.

Если вы под головным коммитом имеете в виду самый последний и нужно «удалить» предыдущий коммит, то можно использовать опцию --onto, предназначенную для перемещения произвольных цепочек коммитов на новое место:

git rebase --onto <новая база> <старая база> <конец цепочки>

или для вашего случая:
git rebase --onto HEAD~2 HEAD~1 HEAD

o———A ← HEAD~2
     \
      B ← HEAD~1
       \
        C ← HEAD

Получим:

o———A ———С' ← HEAD
     \
      B

Единственный такой проект, о котором я слышал — это разработка ядра Linux. Там изначально велась разработка по почте. Да и сейчас кажется ничего не изменилось. На гитхабе мы видим лишь зеркало проекта. Гит изначально был придуман Торвальдсом специально так, чтобы он максимально прозрачно интегрировался в такой процесс. Даже коммиты при просмотре выглядят как электронные письма — там есть имя и мыло автора, тема, тело с подробным описанием изменений…

А ответ на вопрос «как?» вы найдете в официальной книге Pro Git. Там этому посвящена целая глава. Учебник продолжает дополняться и переписываться сообществом, в том числе и на русском.

Вы наверное забыли задать имя для собственной ветки.
Сейчас создайте новую ветку, с именем, которого ещё нет на гитхабе и тогда она ни с кем не будет конфликтовать
Например так:

git branch ветка # придумать название вашего проекта
git switch ветка # сделать эту ветку текущей
git push -u origin ветка # отправить текущую ветку в ветку «ветка» и связать их