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

Когда авторизация по ключу, то не важно под каким локальным пользователем вы делаете push. Важно то, куда вы ранее сохранили открытый ключ на сервере. Если в /root/.ssh/ то и авторизует вас под root. Тут даже не важно, какое имя пользователя вы там вписали в URL remote production.

Но это не точно

Вот ещё версия:
После push на сервере срабатывает post-receive хук от имени рута и всё ломает. Может такое быть?

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

Если внешний репозиторий ваш личный и вы просто хотите его убить и заменить своей историей, то сделайте git push --all --force

Команда push требует чтобы вы сообщили гиту куда отправить и что отправить: git push <remote_repo> <local_branch>
Если только ранее это ещё не было сделано с -u.

Но можно включить режим автоматической привязки
git config push.autoSetupRemote true

Тогда простой git push даже без -u будет текущую новую ветку отправлять в remote origin с таким же именем ветки и автоматически связывать локальную и внешнюю ветку.

Не надо ничего делать ВМЕСТО.
Лучше думайте на тем, ПОЧЕМУ вы работаете долго без синхронизации с базовой веткой?
А как делать синхронизацию, дополнительными коммитами слияния или пересборкой ветки на актуальном мастере, это уже дело вкуса.

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

git rm --cached "r0_code/trainee/Java_Полное_руководство_Герберт_Шилдт,_10_е_издание.pdf"
git commit --amend

• Если файл добавлен в старом коммите, то можно поправить этот коммит через команду rebase --interactive
Как пользоваться командой смотрим в инструкциях к гиту.


• Самый простой и надёжный способ вычистить репозиторий от файла — использовать скрипт filter-repo

git filter-repo --invert-paths --force --path "r0_code/trainee/Java_Полное_руководство_Герберт_Шилдт,_10_е_издание.pdf"

Последний вариант полностью автоматизирован и удалит файл сразу из всех веток.

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

Да даже git init никогда не удалит существующий репозиторий, она только создает его, если его ещё нет. На существующем репо она ничего не удаляет.
В гите вообще сложно что-то удалить, тем более случайно. Не бойтесь практиковаться.

Команда rm -rf .git в каталоге проекта поможет.

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

Сейчас я бы на твоём месте первым делом распаковал нужную ветку в рабочий каталог заново.
git reset --hard dev

Если выдаст ошибку, то значит внутренняя структура репозитория повреждена.
Можно попробовать запустить обслуживание.
git gc --auto

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

Если осталась исходная нормальная копия репозитория на другом компьютере, то лучше забрать её, чем пытаться вылечить эту копию. На старом компьютере сделай нормально push на гитхаб, а на новом компе разверни копию через clone. Это самый простой способ.

Какой-то плагин всё сломал. Помогает выключение и включение плагинов для Git.

LVitA, странно что вопрос подвис.
Если .gitignore визуально правильный, но не работает, то причина скорее всего в кодировке. Может быть случайно BOM-заголовок у файла добавился?
Пересохраните его в однобитной кодировке.

Есть замечательный гайд – ProGit на русском.
Как можно пользоваться гитом и не знать основ?
А если бы вы знали основы, то не вас не смутили бы элементарные вопросы мастера установки. Там нет ничего сложного. Если речь про Windows, то конечно меняю редактор по-умолчанию. Vim это не моё.

Сначала спрячем незакоммиченные правки. Нам нужен чистый рабочий каталог.
git stash
Запустим процесс переписывания истории
git rebase -i AAA
В текстовом редакторе заменяем перед коммитом BBB слово pick на edit
Сохраняем, выходим
Git начнёт процесс переборки ветки и остановится на коммите BBB
и покажет инструкцию

Stopped at BBB
You can amend the commit now, with

 git commit --amend 

Once you are satisfied with your changes, run

 git rebase --continue

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

git stash pop
# скорее всего вылезут конфликты, которые нужно разрешить и 
git add .

Затем собственно поправить коммит BBB
git commit --amend
Далее по инструкции
git rebase --continue
Если всё хорошо, увидим

Successfully rebased and updated refs/heads/master.

Если конфиги уже в репозитории, то никакой gitignore на них не подействует.

Но временно игнорировать изменения в файле можно командой:
git update-index --assume-unchanged <file>
Это защитит файл от случайной переиндексации и попадания правок в коммиты.
Git будет считать что файл не изменялся, значит сами эти нежелательные правки не попадут в коммиты и, следовательно, не улетят в общий репозиторий. Коллеги не узнают что что мы отредактировали файл у себя локально.

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

git rm --cached '.vs'
git add . 
git commit
git push

Да, можно. В GitHub это называется Merge методом Squash.

git switch prod
git merge --squash dev
git commit

По факту операция склеивает все коммиты вашей тематической ветки в один и делается cherry-pick полученного коммита в prod. Поэтому после вам желательно удалить тематическую ветку, так как она станет неактуальной. Ну либо просто начать новую от актуального prod. Если продолжить работать в старой цепочке коммитов, то вы можете словить неприятные глюки в дальнейшем.

Расшифруйте свою фразу

Пришлось откатить последний pull с репозитория.

Пришлось что-то сделать? Что именно вы сделали? Либо вы только собираетесь что-то сделать? Например, Pull подгрузил актуальный мастер с GitHub, в котором коллеги сделали какую-то работу и вы теперь хотите выкинуть их работу в корзину и откатить проект?

git revert 6759221be
Эта команда отменяет действия некоего коммита 6759221be. Обычно это самый правильный и безопасный способ отменить какие-то изменения, при работе в команде.

git checkout 6759221be
Этой командой мы отрываем голову и выходим из мастера в неопределённое состояние. Непонятно чего вы хотите этой командой добиться. Делать в данный момент Push бесполезно, так как вы НЕ в мастере. git push -f резонно вам говорит что локальный мастер согласован с внешним. Ведь вы ничего не меняли в мастере, а просто переключили состояние рабочего каталога на левое состояние, не совпадающее ни с какой веткой.

Конечно можно вернуться в мастер и сделать git reset --hard 6759221be
Но таким образом вы создадите фактически новый мастер и если его принудительно отправить на гитхаб, то всё равно

«Кто нибудь начнет путаться, забудет что теперь надо использовать условный master2»,

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

Я так и не понял, что именно вы сделали или хотите сделать.
Есть подозрения, что откатить вы хотите не pull, а push со своим не очень удачным коммитом.

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

LANG=en_EN.utf-8

git reset $(git commit-tree HEAD^{tree} -m "Новое начало истории")

Уже есть удобный GitHub CLI