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

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

Сегодня такую чистку делают буквально в один клик.

# Вычистить каталог Media из истории проекта
git filter-repo --path "Media/" --invert-paths

Грохнул ее из кеша git rm -r --cached ./folder_name
Удалил с диска саму папку

Можно было это сделать в один шаг git rm -r "./folder_name"

Что делаю не так?

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

добавил в .git/config строку

Нельзя редактировать конфиг руками. Всегда используйте команду git config

Как мне исключить папку только на одной локальной копии репы?

Папку исключить нельзя, но временно пометить файлы в папке, чтобы Git на них не смотрел:
git update-index --assume-unchanged "folder/*"

Станислав,
Git это программа, портированная из Linux, поэтому тут не работает синтаксис Windows. Мы используем в путях слеши «/» вместо обратных слешей «\». И переменные окружения вызываются иначе $USERPROFILE либо можно попробовать $HOME/.gitignore
Но я бы тут просто вписал полный путь до файла и желательно заключить путь в кавычки.

Гит так не работает.

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

нашёл нужный код, вырезал из фиче-ветки-1, закоммитил;

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

Возможно помогло бы склеивание ветки (squash) при слиянии. Чтобы факт удаления файлов в принципе не появлялся в истории ветки.

Я бы в таком случае разбил коммиты на более мелкие и пересобрал ветки в нужных конфигурациях. Это удобно делать в нормальных GUI-клиентах, например в SmartGit.

Лариса, RAW-ссылка гитхаба отдаёт правильный файл, но с типом контента text, поэтому браузер показывает его как текст, а не рендерит html.
Но можно обойти эту проблему используя сторонние сервисы

https://raw.githack.com/<usergithubname>/<repo>/<branch>/path/to/test.html

Отменить авторизацию легко

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

При следующем пуше снова попросит авторизацию.