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

А после перевода из 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

Источник

У VPS нет особенностей, это такой же компьютер. Вы делаете всё то же самое, что ранее сделали на своём компьютере, чтобы получить доступ к этому репозиторию. У вас видимо проблема с непониманием самого процесса аутентификации.

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

Если предпочитаете ssh, то процедура тоже ничем не отличается от описанной в документации. Просто следуйте официальным инструкциям.

Если вы админ, то интерфейс выглядит так:

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

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

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

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

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

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

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

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

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

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

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

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

Уберите слеш в начале ссылок, чтобы путь был относительно расположения html-файла а не от корня сайта.