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

Работу в VSCode начинайте с команды Открыть каталог, чтобы этот каталог стал текущим для встроенного терминала. В противном случае ваш терминал открывается в домашнем каталоге и вы в этом каталоге зачем-то инициализировали репозиторий.

Чтобы исправить ошибку, удалите этот репозиторий
rm -rf "~/.git"
И создайте репозиторий заново в правильном месте — в каталоге вашего проекта.

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

То, что вы описали, называется squash-коммттом. Это когда все коммиты тематической ветки склеиваются в один, и этот коммит добавляется в конец основной ветки, без сохранения связи с исходной тематической веткой. Это проще всего делать в момент слияния вашего Pull Request на GitHub. Выбирайте там метод слияния Squash and Merge.

В корне проекта создайте такой .gitignore

# Игнорировать все файлы и папки в корне проекта
/*

# Не игнорировать папку src и сам этот gitignore
!/src/
!.gitignore

# Игнорировать содержимое папки controllers
/src/controllers/*

# Кроме одного файла
!/src/controllers/controller.env

# Игнорировать содержимое папки users
/src/users/*

# Кроме одного файла
!/src/users/users.env

Чтобы я мог клонировать в app отдельный репозиторий и гит всего проекта не следил за гитом этого мини-репозитория

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

просто само наличие папки с таким названием при клонировании

Так и получится. При клонировании создастся пустая папка app. И её содержимое продолжит игнорироваться, даже без наличия вложенного репозитория.

А после перевода из SVN в Git вы делали сжатие репозитория?
git gc --prune=now --aggressive

Думаю проблема где-то тут. Ведь в репозитории ядра Linux больше миллиона коммитов, но это не мешает разработчикам с ним работать.

Я не понимаю чего вы нашли в Git Extensions. Мне кажется это худший инструмент для Git, после TortoiseGit.
Рекомендую SmartGit или Git-плагин в средах разработки от JetBrains.

Ещё, как вариант, обрезать старую историю. Можно сделать два репозитория — архивный и актуальный. В последнем допустим оставить коммиты за последние пару лет. Кому вдруг понадобится покопаться в древних коммитах, тот всегда сможет прицепить старую историю. Рецепт как это сделать есть официальном учебнике.

В Git отсутствует последовательный номер редакции, потому что Git это распределенная система, а не централизованная, как SVN. Вместо этого Git использует уникальные хеши коммитов для идентификации версий.

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

Ветку надо создавать новую, а не пытаться переименовать main.

Когда вы клонировали проект, то ваша локальная main автоматически связалась с внешней main на гитхабе. От переименования эта связь никуда не денется и при дальнейшем push вы будете отправлять всё равно в main, что запрещено у вас. Поэтому вы и получаете ошибку.

Задача решается легко

git config --global url."git@github.com:".pushInsteadOf "https://github.com/"

Спасибо Lynn «Кофеман» за наводку.

Вот только не понятно, зачем это автору.

потому что задолбаешься вбивать токен

Аутентификация делается один раз, а дальше её запоминает Git Credential Manager.
Как и не придется каждый раз вбивать парольную фразу ssh-ключа, если включить агент.

Ну так создайте ещё одну ветку и вынесите туда только часть изменений. Например, через 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