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

Если нужно вытащить отдельные файлы из другой ветки, используйте checkout
git checkout ветка -- путь/к/файлу
Это извлечет файл в рабочий каталог. Останется только его закоммитить в текущей ветке.

remote amvera already exists

Вы пытаетесь добавить remote с именем amvera,

git remote add amvera https://git.amvera.ru/<имя-пользователя>/<транслитерированное-имя-проекта>

Если вам пишет, что такой remote уже существует, значит вы ранее уже это сделали.
Зачем вы пытаетесь добавить адрес повторно?

Подскажите, что с этим можно сделать?

Если вы хотите заменить ранее добавленный адрес, то либо предварительно удалите предыдущий remote
git remote remove amvera
либо используйте команду замены
git remote set-url amvera ...

Почитайте, что делает опция --hard команды reset.

Историю изменения коммита посмотреть невозможно, так как это неизменяемая сущность по определению. Через amend вы лишь создаёте новый коммит и перемещаете указатель текущего состояния на него. Эти перемещения вы видите в локальном журнале reflog. Вы не можете видеть reflog внешних репозиториев. В лучшем случае, вы увидите историю «изменений» в Pull Request на GitHub.

Я имею ввиду предыдущую версию коммита до amend. Локально же можно переключиться на него через checkout.

Эти осиротевшие коммиты не удаляются сразу, поэтому вы некоторое время ещё можете их извлечь из репозитория через checkout или reset. Но они не принадлежат никакой ветке, поэтому никуда не отправляются при push и не получаются при fetch или clone, поэтому вы не сможете на них переключиться, так как их нет локально. Они остались в «мусоре» внешнего репозитория, который не скачивается при clone.

Нет, рекурсия работать не будет. Гит увидит, что внутри каталога лежит вложенный репозиторий и проигнорирует его. А в своей базе пометит этот подкаталог как поддерево (subtree), чтобы не сломать.

Вы пытаетесь соорудить какой-то жуткий костыль только лишь потому, что поленились изучить инструмент, в котором работаете. Поэтому для вас Git сейчас представляется как некая шайтан-машина, которой вы скармливаете команды, которые не понимаете, и в результате получаете ещё более непонятные «неожиданные результаты». Просто потратьте несколько дней, чтобы изучить азы. Не зубрите непонятные команды, а постарайтесь понять логику гита. А она — эта логика предельно проста и гениальна.

не является сложной задачей что-либо сломать в своем проекте

Сломать что-то в гите довольно сложно. Вам может только показаться что всё сломалось, но это лишь потому, что вы не понимаете, что делаете.

каким-то образом снес половину коммитов

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

Поэтому было бы неплохо как-либо сохранять прошлые версии Git репозитория

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

Мой вам совет: Пройдите 16 коротких бесплатных уроков и полу́чите просветление.

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

Например вы можете удалить папку в рабочем каталоге и затем не забыть закоммитить это изменение.

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

git rm —cached ".idea"
git commit -m "Delete .idea"

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

Запомните! Простое редактирование файла .gitignore не удаляет никакие файлы из репозитория. Вам надо удалить файлы самостоятельно, создав коммит удаления.

Гит — это распределенная система. Мы можем иметь много равноправных репозиториев и обмениваться информацией между ними. Тот репозиторий, в который мы сейчас коммитим, будет локальным. А другие репозитории, в которые отправляем (push) или из которых получаем (fetch), они внешние (вышестоящие, upstream, remotely)
Часто говорят удаленные, но это не очень уместный перевод слова remote в данном контексте. Потому что появляются странные формулировки типа «удалить удаленный»

Именем upstream ещё принято обозначать исходный репозиторий, от которого мы сделали форк на GitHub, так как имя origin уже занято и указывает на форк. Поэтому адрес исходного репозитория, при необходимости, сохраняем в переменной upstream. В данном контексте это просто традиция, и назвать ссылки на внешние репозитории мы вольны как угодно. Команда git remote лишь создаёт переменные, в которых мы храним URL внешних репозиториев, чтобы затем использовать имя переменной в командах, вместо того, чтобы писать длинный URL.

Попробовал отправить для теста — вылезло привычное окно Credential Manager с выбором способа авторизации. Выбрал через браузер и всё ушло как по маслу в пару кликов. И никакой возни с SSH-ключами.


Какая у вас версия Git? Какая операционка?
Нормально установленный Git использует Credential Manager для авторизации на серверах.

у всех работает сразу пуш и не требует аутентификации

Это конечно же не так. В первый раз всегда требуется авторизация.

Не знаю, что делать, и даже гайда нет по этому поводу нормально в интернете

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

Вы не дочитали до конца сообщение об ошибке

Hint: You have divergent branches and need to specify how to reconcile them.
Hint: You can do so by running one of the following commands sometime before
Hint: your next pull:
Hint: 
Hint:   git config pull.rebase false  # merge
Hint:   git config pull.rebase true   # rebase
Hint:   git config pull.ff only       # fast-forward only
Hint: 
Hint: You can replace "git config" with "git config --global" to set a default
Hint: preference for all repositories. You can also pass --rebase, --no-rebase,
Hint: or --ff-only on the command line to override the configured default per
Hint: invocation.

Гит вам говорит, что история веток разошлась и нужно явно указать, каким методом сливать разные ветки при pull.
Обычно принято использовать метод merge, поэтому мы либо каждый раз это уточняем:
git pull --no-rebase
Либо сохраняем глобальный параметр для всех ваших репозиториев:
git config --global pull.rebase false

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

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

git config --local user.name ...
git config --local user.email ...

Если хочется непременно разные аккаунты на гитхабе, то

Как разлогиниться в гитхабе?

Если отправляете по HTTPS, то придется каждый раз сбрасывать авторизацию после предыдущего пользователя

echo "url=https://github.com" | git credential reject

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

Для этого мы создаём в файле конфигурации ~/.ssh/config несколько виртуальных хостов

Host github-alice
        Hostname github.com
        IdentityFile=/home/user/.ssh/alice_key

Host github-bob
        Hostname github.com
        IdentityFile=/home/user/.ssh/bob_key

И поправьте ссылки на origin в своих репозиториях используя псевдоним виртуального хоста

git remote set-url origin git@github-alice:OWNER/alice-repo.git

Есть официальная инструкция

How do I use multiple accounts with the same hosting provider using SSH?

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

Принудительное удаление этих файлов решит проблему.

Воспользуйтесь инструкцией по установке с официального сайта Git LFS

предлагает использовать либо одно, либо другое

Кто такое предлагает? Наоборот, в большинстве случаев хочется оставить и то и другое.

Как правильно решить этот конфликт?

Как обычно, у себя на компьютере подгружаете в свою ветку новые коммиты из целевой ветки common, которые там появились после того, как вы свою ветку feature создали. И в этот момент разрешаете конфликт локально, а вовсе не на гитлабе.

Верно. Если не делать коммит, то он и не получится.

Permission to {repo} denied to {user}

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

Параметры user.name и user.email не имеют никакого отношения в вашим GitHub-аккаунтам.
Это лишь реквизиты, которыми будут подписаны новые коммиты на вашем компьютере и всё.
Вы же не думаете, что достаточно знать ваше полное имя и мыло, чтобы войти в аккаунт?

Если интересно, какой параметр в каком файле сохранён, воспользуйтесь командой.
git config --list --show-origin
system лежат в каталоге самого гита и действуют глобально на репозитории всего компьютера.
global хранятся в каталоге пользователя и влияют на все репозитории текущего пользователя.
local сохраняются в каталоге репозитория и действуют только на этот репозиторий.
Одинаковые параметры могут дублироваться в разных конфигах и тогда используется самый локальный.

Но! Ваша ошибка при push связана лишь с неправильной авторизацией. Разбирайтесь с ней, а не с тем, как подписаны коммиты.

Авторство коммитов на авторизацию не влияет вообще, от слова совсем. Можете подписаться хоть как Билл Гейтс. После отправки коммитов на гитхаб они не изменятся. Коммиты вообще в принципе никогда не изменяются, по определению. Можно лишь их пересоздать заново с другим содержимым и описанием.

Команда git remote prune origin удалит ссылки на вышестоящие ветки, которых уже нет на сервере origin, но не тронет соответствующие локальные ветки, которые были с ними связаны.

Удалить локальные ветки, которые связаны с несуществующими внешними можно примерно таким скриптом:

#!/bin/bash

# Получить список веток, которых уже нет на внешнем сервере
missing_branches=$(git branch -vv | grep ': gone]' | awk '{print $1}')

# Удалить каждую локальную ветку, у которой удалена её вышестоящая ветка.
for branch in $missing_branches; do
    git branch -D $branch
done

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

не позволяет использовать 1 ключ в нескольких репозиториях

Также наверное нельзя одновременно несколько разных ключей использовать для доступа к одному серверу.

Скорее всего нужно подсказать хосту, какой именно ключ использовать для каждого из подмодулей.
Для этого мы создаём в файле конфигурации ~/.ssh/config несколько виртуальных хостов

Host github.com-module-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/module-1_deploy_key

Host github.com-module-2
        Hostname github.com
        IdentityFile=/home/user/.ssh/module-2_deploy_key

И поправьте ссылку на подмодуль в .gitmodules используя псевдоним виртуального хоста
git@github.com-module-1:OWNER/repo-submodule-1.git

Сам не проверял, пишу основываясь на официальной документации GitHub:
Authentication / Connect with SSH / Managing deploy keys

У Git нет команды «подключиться к репозиторию». Да и как к нему подключаться, если репозиторий это просто каталог? Вы наверное пытаетесь утилитой ssh подключиться к какому-то серверу, на котором лежит репозиторий. А зачем? Git-хостинги не предоставляют доступа к командной оболочке своих серверов, это же не vps.