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

Уже есть удобный 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

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

Pull Requests не являются частью репозитория Git и не переносятся при клонировании соответственно.

Чтобы откатить ветку используется reset, а не checkout.

Сделав checkout вы ушли из мастера в неизвестность (detached head). Последующие коммиты будут приклеиваться в безымянную цепочку коммитов, а не в мастер. Мастер же не изменится, так как вы уже не в нём.

Начиная с версии 3,2 поддержка Git встроена

Git заточен на работу в локальной файловой системе.
Вам религия не позволяет нормально клонировать репозиторий к себе?

старый мастер назвать old-master и текущую ветку, переименовать в master

git branch -M master old-master # переимоновать старый мастер
git branch -M master # переименовать текущую ветку в master

Но зачем всё это? old-master будет по-прежнему связан с origin\master.
Если хочется обновить и эти связи, то используется push

git push --set-upstream origin old-master # перенаправить на новую ветку
git push -u --force origin master # пересоздать внешний master

Если origin и VPS это разные места, то VPS не увидит этих ваших переименований.
Там тоже придётся связи перенастраивать.
Например через git pull --rebase на VPS и на компьютерах всех коллег, если вы работаете в команде.

Снова повторю вопрос: зачем вам эти сложности?

git remote rename - но это для переименования удаленных веток (как я понял)

Нет, это для переименования remotes — ссылок на внешние репо.

Вы смешали тёплое с мягким. Внутри папок ветки, а внутри веток снова папки.
Что вообще имелось в виду?

На всякий случай попробуйте клонировать оптом вместе с подмодулями.
git clone --recurse-submodules <GitLab>

Шестой пункт выполняйте первым, а первый и второй вообще не делайте, они не нужны.
Тогда всё заработает.

git remote set-url origin <адрес форка>
Либо ещё лучше так

git remote rename origin upstream
git remote add origin <адрес форка>

Чтобы иметь возможнось подгружать к себе обновления основного репозитория
git fetch upstream

Всё это можно сделать через меню IntelliJ IDEA
Поищите пункт Manage Remotes…

Нет, не на main, а из main.

Команда git push -u origin main делает отправку локальной ветки main во внешний репозиторий origin, но ветки main не существует, о чем вам и сообщили в ошибке.

Вам нужно либо переименовать master в main:
git branch -M main

Либо так и написать, что вы хотите master отправить во внешний main
git push -u origin master:main

Но судя по скрину, у вас репозиторий не пустой. Вы уже создали там ветку с первоначальным коммитом. Поэтому вы не сможете просто так туда сделать push, так как ваши ветки не имеют общей истории. Это РАЗНЫЕ деревья. В таких случаях можно просо пересадить локальную ветку на вершину внешней через rebase. Либо создать ПУСТОЙ репо, как вы и сделали.

Откройте настройки и введите в поиск Editor: Format On Save
Там либо отключите форматирование при сохранении, либо настройте его, чтобы форматировался не весь файл а только изменённые строки.


Ну либо сделайте рефакторинг проекта отдельным коммитом и договоритесь в команде о соблюдении стиля в дальнейшем.

Вы можете обеспечить единство форматирования в своей команде, создав файл конфигурации Prettier для вашего проекта. После создания такого файла и его добавления в проект вы можете быть уверены, что все члены команды используют одинаковые правила форматирования.

Вы наверное не совсем понимаете логику работы гита, раз такой вопрос возник.
Репозиторий надо рассматривать как дерево состояний проекта. Каждый коммит это определённое состояние. Название ветки это лишь указатель на некоторое состояние.

создал локальную ветку задачи branchTaskName от локальной develop-ветки (предварительно ее обновив)

Точнее вы создали тематическую ветку не от другой ветки, а от конкретного состояния, на которое указывал в тот момент указатель develop в распакованной (checkout) в рабочий каталог ветке.

Нужно ли мне обновлять свою ветку задачи branchTaskName свежими изменениями?

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

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

Тут тоже странное утверждение. У вас неоткуда взяться проблемам при отправке (push) изменений во внешний репозиторий. Проблемы могут возникнуть уже после, когда вашу ветку будут интегрировать (merge) с основной веткой (develop). Чтобы избежать этих проблем мы заранее предпринимаем определённые действия.

Способов собственно два:

1) Мы забираем новое состояние develop в свою тематическую ветку через коммит слияния. И для этого вовсе не обязательно переключаться в локальную develop, обновлять её (pull) а затем возвращаться к себе чтобы сделать git merge develop. Это бессмысленные манипуляции. Достаточно просто скачать к себе в локальный репозиторий обновления внешнего репозитория git fetch (Лайвхак: эту операцию можно автоматизировать. Настройте автоматическое выполнение fetch по расписанию, и у вас всегда будет под рукой доступ к актуальному проекту). Затем сделайте git merge origin/develop. Указатель origin/develop это и есть ссылка на состояние проекта на момент последнего скачивания (fetch). В принципе эти два шага эквивалентны одной команде git pull origin develop — внутри делается всё то же самое.

2) Второй способ — пересадить вашу ветку на новое актуальное состояние проекта (rebase). Выглядеть будет так, если бы вы начали работать над фичей вот только что, и тут точно не возникнет конфликтов, так как база ветки актуальная. Это делается тоже в два шага. Сначала убедимся что у нас всё актуально git fetch, затем собственно пересадим ветку на актуальное состояние git rebase develop. Последний вариант мне нравится тем, что история не засоряется коммитами слияния. Но тут предполагается, что тематическая ветка принадлежит только вам и никто больше в ней не работает. Так как после пересадки её придётся удалять из внешнего репозитория и создавать там заново через git push --force. Если работа над фичей ведётся совместно с коллегами, то такой рабочий процесс не очень подойдёт.

Если вы не коммитите напрямую в master и в develop, то держать их у себя локально (делать checkout в рабочий каталог) тоже нет смысла. Вы всегда можете начать новую тематическую ветку от актуального состояния, на которое ссылаются origin/master или origin/develop. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.

Тоже думаю что у вас какой-то странный workflow.

брал ветку разраба, сквошил изменения, видел полный набор изменений, ревьювил и исправлял их и формировал итоговый коммит, который черри-пиком переносил уже в develop

Чтобы видеть все изменения не нужно ничего сквошить.
Исправления должен делать сам разработчик, зачем вы делаете это за него?
Черипикать тоже непонятно зачем.

бывают конфликты слияния, что тратит дополнительное время

Это тоже забота разработчика. Пусть перед отправкой своей работы на рецензию делает git merge develop и устраняет конфликты сам заранее.

неудобно, что ревью приходится проводить в GitLab.

Что мешает поставить плагин и работать там где удобно?

При пуше, Git пытается авторизоваться с помощью Git Credential Manager Core, который как раз написан с использованием .NET Framework. В первых версиях десятки был встроен .NET Framework 4.6, но это было много лет назад. Если не отключены обновления, то .NET у вас должен быть актуальным 4.8.
Скорее всего вы «забыли» установить обновления.