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

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

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

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

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

Последний коммит отмените, а первый пересоздайте

git reset HEAD~1
git commit --amend

Либо этими командами в терминале, либо мышкой в интерфейсе PhpStorm.

Если задали пароль ключа, при его создании, то он спрашивается при использовании.
Настройки GitHub Desktop тут никак не влияют.

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

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

Если вы хотите выполнить команды вручную, то для этого есть терминал.

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

Ну а по поводу оторванной головы вам подробно ответил Андрей.

Автор коммитов задаётся этими параметрами

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

Но это повлияет только на новые коммиты.
Если нужно поменять старые коммиты, то их можно пересоздать используя скрипт filter-repo

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

Всё очень просто. На портах 80/443 вешаете не сайт, а обратный прокси.
Для Proxmox уже есть готовый контейнер Nginx Proxy Manager LXC
В нем разруливаете сколько угодно сайтов на вашем белом IP, там управление мышкой в веб-интерфейсе.
И сертификаты для https там создаются легко.

Если нужно вытащить отдельные файлы из другой ветки, используйте 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

Пробовали делать Rescan? Чтобы сервер узнал, что агент обновился.

Вы не можете войти в каталог, потому что это не каталог вовсе, а ссылка. Стрелочка как бы намекает.
Это может быть символическая ссылка (symlink), либо подмодуль (submodule), либо вложенный репозиторий (subtree). Скорее всего последнее и вы ранее инициализировали дополнительный репозиторий внутри той папки. Гит это распознаёт и не будет добавлять содержимое каталога в вышестоящий репозиторий. Поэтому гитахабу нечего вам показать внутри того каталога, так как там пусто. Содержимое папки осталось только в рабочем каталоге и не попало в репозиторий.

Если это так, то вот тут пример как лечить.

• Удалить папку .git из подкаталога Originalite
  
• Удалить эту ссылку из репо git rm --cached Originalite
  
• Затем таки добавить папку в репо git add Originalite
  
• Закоммитить и отправить на гитхаб.