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

В 2023 году рекомендованным методом является использование пакета filter-repo
Задача решается буквально одной командой

# Клонируем репо в соседний каталог
git clone --no-local . "../repo2" # тут будет новый репозиторий
# Перейдем в новый репо 
cd ../repo2 
# Оставим в проекте только содержимое подкаталога folder2, 
# сделав его новым корнем проекта
git filter-repo --subdirectory-filter "folder2/"

В любой непонятной ситуации смотрите git status — там будут все подсказки.

Серый цвет у вас скорее всего означает что эти объекты подпадают под игнор.
Желательно вывести их из игнора, иначе придется индексировать принудительно каждый файл с опцией force
И не забывайте, что используемый вами ключ --all не будет добавлять в репо новые файлы, обработаются только уже существующие но измененные файлы.

Вы же не на пустом месте ветку создали? В момент создания ветки «в неё» сразу попадают все предыдущие коммиты вниз по истории дерева коммитов. И после отправки, в ветке внешнего репозитория появится ровно столько коммитов, сколько было в локальном.

Другими словами — ветка это не какое-то хранилище, в которое складываются коммиты. Ветка это указатель на точку на дереве коммитов проекта. А дерево уже содержит все коммиты проекта.

Неважно, что вы делали, гит перед каждым изменением записывает хэш указателя текущей ветки в специальный журнал — reflog. Соответственно вы можете этот журнал посмотреть командой git reflog
А можно просто сослаться на порядковый номер в журнале и откатить текущую ветку на два шага назад:
git reset --hard HEAD@{2}
Как-то как.

Если вы под головным коммитом имеете в виду самый последний и нужно «удалить» предыдущий коммит, то можно использовать опцию --onto, предназначенную для перемещения произвольных цепочек коммитов на новое место:

git rebase --onto <новая база> <старая база> <конец цепочки>

или для вашего случая:
git rebase --onto HEAD~2 HEAD~1 HEAD

o———A ← HEAD~2
     \
      B ← HEAD~1
       \
        C ← HEAD

Получим:

o———A ———С' ← HEAD
     \
      B

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

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

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

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

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

git reset HEAD~1
git commit --amend

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

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

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

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

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

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

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

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

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

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

Если нужно вытащить отдельные файлы из другой ветки, используйте 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 сказано, что нужно создать пароль приложения.
Из соображений безопасности, обычные пароли запрещены. Как я написал выше, мне лень и предпочитаю просто кликнуть мышкой и разрешить доступ.