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

Ну так создайте ещё одну ветку и вынесите туда только часть изменений. Например, через cherry-pick отдельных коммитов с предыдущей ветки. Либо через soft reset собрать новую ветку, оставив только нужное.

по файлу копировал содержимое

Гит как раз и был придуман, чтобы не делать такое.

Либо через интерфейс Гитхаба, либо через Андроид Студию

Studio это отличный Git-клиент — работайте там.

Я сделал новую ветку от dev ( к примеру ветка test ) и хотел через git pull забрать изменения с удаленной основной ветки dev

Зачем создавать ветку от старого состояния dev, а потом обновлять? Не лучше ли сначала скачать к себе всё, а потом создавать тематическую ветку от актуальной dev? Распаковывать локально ветку dev смысла нет, если вы напрямую в неё коммитить не будете.
Я бы делал так:

git fetch # скачать всё новое с внешнего репо
git checkout -b origin/dev # создаем ветку от актуальной dev

There is no tracking information for the current branch

Логично же? Вы не связали новую ветку ни с какой внешней и как Git поймет, откуда скачивать?
У команды Pull в таком случае должно быть два дополнительных параметра, указывающие из какого репозитория и из какой ветки обновляться
git pull origin dev

забирать с dev но пушить в свои ветки

это возможно организовать, но вам это не нужно. А вдруг вы захотите поработать на другом компе? Как тогда будете забирать обновления своей ветки? Не усложняйте.

Гит достаточно умен, чтобы не создавать рекурсию и не добавлять вложенный репозиторий в вышестоящий репо. Вы же не собираетесь отслеживать те тысячи файлов, которые внутри вложенных подкаталогов .git?

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

Если вам не важна старая история, то просто удалите те два репо (удалите папки .git), затем инициализируйте общий репо.

Если история важна, то пакет filter-repo поможет объединить репозитории в один с реорганизацией структуры каталогов.

В обоих случаях получится один репо без вложенных. А вложенные будут либо удалены, либо новый репо мы создадим новый репо в другом месте, чтобы не потерять старые.

Как уже сказали, возможность указать название начальной ветки, отличное от master, появилось в Git версии 2.28.
Вы всегда можете переименовать master после инициализации, но лучше обновиться.

И не важно, есть в текущем каталоге файлы или нет. Зачем вы акцентируете на этом внимание?

Ваш второй вопрос к инициализации не относится:

И почему пуш делается обязательно с --set-upstream?

Не обязательно. Этот ключ лишь добавляет связь между локальной и внешней веткой. Чтобы в следующий раз отправлять коммиты просто командой push. Git уже будет помнить, в какой внешний репозиторий отправлять и в какую ветку.

И самое важное:
Никогда не вбивайте команды, смысл которых не понимаете. Сначала почитайте их описание.

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

git log --oneline --merges --first-parent хэш_коммита..HEAD | tail -n 1

Либо просто в IDE посмотреть глазами ближайший коммит слияния в дереве.

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

Ваша проблема в том, что готовый проект после компиляции складывается в каталог 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 забыли установить.