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

можно пикать комиты, но только не как комиты, а как изменения в рабочий каталог, и потом их просто комитить и все

Неважно, сразу коммит создаётся или вы его потом руками сделаете — результат получится идентичный. Если не понимаете, к чему могут привести черри-пики, то не используйте их.

Почитайте пару статей про это из цикла Хватит копировать, пора сливаться:
Часть 1. Конфликт слияний
Часть 2. Конфликт слияний, который так и не произошёл (а должен был)
Третью часть почему-то так и не перевели, но там описано как избежать проблем.
Part 3: Avoiding problems by creating a new merge base

Допустим нам известен хеш «уничтоженного» коммита и мы находимся в нужной ветке.
Мы можем скачать коммит зная только его хеш.
На тестовом репозитории у меня сработал такой сценарий:

git fetch origin cb5ca32b84e1b53466c067524bc5841180dc295b
git reset --hard cb5ca32b84e1b53466c067524bc5841180dc295b

Если порт нестандартный, то надо его указать в url

git clone ssh://git@server:43055/blablabla/bla-bla-bla.git

Замените ваши четыре шага одной командой

git clone --depth=1 --branch=main <repo link> <site-dir>

— скачать только состояние на последний коммит ветки main.
Остальная история на хостинге не нужна.

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