Станислав Бушуев

Вы наверное хотите скрыть не сам Pull Request, а код, который виден там.
Но ведь этот код студенты отправляют из своих открытых проектов в ваш открытый проект. Значит код в любом случае виден всем в интернете, причем даже без создания PR.
Единственный способ скрыть код — публиковать его в закрытые проекты.
Пусть студенты создают приватные репозитории и дают вам доступ туда.

старый мастер назвать 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 — ссылок на внешние репо.

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

создал локальную ветку задачи 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. Так вы не наступите на грабли, когда люди забывают переключиться из мастера и начинают коммитить туда. Нет мастера — нет проблем.

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

Гит пушит не файлы, а ветки с коммитами, поэтому внешний репозиторий будет содержать точную копию локальных данных. Репозиторий по сути один, и он распределённый. Так устроен Гит. Нет разницы локальный или внешний.
Не храни вообще конфиги в репозитории, если он уйдёт в паблик!
Поэтому правильный ответ на поставленный вопрос — нет.

Но ты можешь распаковать (checkout) разные ветки в разные каталоги (worktree). И уже для каждого сможешь сделать нужные настройки. Так ты получишь желаемое и пароли не придётся светить в публичном внешнем репозитории.

Такое может произойти из-за неправильной настройки символа переноса строки.
Читай тут как исправить.

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

Все сценарии приблизительные, потому что каждая проблема требует комплексоного подхода и знания возможностей инструмента, поэтому не поленись, а почитай вот это внимательно и полностью
https://git-scm.com/book/en/v2

git reset --hard 0821842 # откатить локально 
git push --force # откатить на внешнем, это удалит и создаст заново ветку

Master обычно имеет защиту от удаления, тогда можно поступить более правильно:

# создать синтетический коммит, отменяющий последние коммиты
git merge --ff $(git commit-tree -p master -m "Rollback to commit 0821842" 0821842^{tree})
git push
# можно ещё для надёжности проверить, что новое состояние действительно совпадает с желаемым
git diff master 0821842

git reset --hard HEAD

Сгенерируй SSH ключ на домашнем компьютере ssh -t ed25519
Добавь публичную часть ключа в свой аккаунт на GitHub
После этого сможешь клонировать.

К каждого устройства должен быть свой ключ. Приватный ключ не должен покидать устройство на котором он был сгенерирован.

правки бывают двух типов:
1. исправление косяков.
2. дополнительные фичи/изменение уже реализованных.

1 делается бесплатно и как можно быстрее.
2 делается за отдельные деньги. или не делается вообще и работа с клиентом прекращается.

есть ещё 3: дать клиенту скидобан на конкретно оговоренный объем дополнительных работ.

это из основного. есть ещё методы, но они уже для постоянных клиентов.

Ну развлекайтесь

$ git update-ref 'refs/heads/-@have-fun!' @^{commit}
$ git switch -- '-@have-fun!'
Switched to branch '-@have-fun!'
$ git branch -v
* -@have-fun! 734a4af Docker
  master      734a4af Docker

Вот Подборка на любой уровень. Я начинал с Таненбаума.