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

Уловка в системе процессорных комманд: 48 c7 45 08 - позволяет загрузить в 64-битную ячейку памяти 32 битное число, автоматически расширяя его до 64 бит.

Смотрите список кодов x64:
0x48 - означает, что следующая комманда работает с 64-битами.
0xC7 - mov immediate (данные в команде)
Дальше идут флаги, указывающие как интерпретировать аргументы, что куда адресовывать и т.д.

Но важно, что команда C7 работает с r/m16/32/64 данными, а аргумент у нее может быть только imm16/32 (третий столбец). Т.е. она принимает или 2 или 4 байта, в зависимости от обвеса, а записывать может до 64 бит. Сравните это с коммандой 0xB8 в той же таблице, она уже может принимать 64 бита.

Если аргумент меньше ячейки памяти, то он расширяется (sign extended) до нужного размера (бит знака копируется влево до упора). Это позволяет записать числено равное значение в более битную ячейку. ведь 32-битное число 0xFFFFFFFF - это -1 в дополнительном бинарном коде, а 0xFFFFFFFFFFFFFFFF - это тоже -1 в дополнительном 64-битном коде.

Компилятор использует вот эту команду, а не 0xB8, потому что сама команда короче, а исполняется так же быстро. Меньше кода, больше всего помещается в кеш и все работает быстрее, да и exe-шник меньше получается.

Восстановить очень легко, так как гит ничего не удаляет из репозитория, по крайней мере сразу.
Команда reset лишь переместила указатель ветки. Полностью удалить что-то крайне сложно.
Вы можете посмотреть через git reflog где был указатель до этого и вернуть его туда обратно.
git reset --hard HEAD@{1}
Данная команда вернёт ветку на состояние, помеченное на вашем скрине как HEAD@{1}
Либо можно скопировать непосредственно sha-хэш места, куда хотите вернуться.

Затем повторить отмену последнего коммита, но уже правильно:
git reset HEAD~1
Такая команда не будет изменять рабочий каталог, а значит ничего из него не удалит.

Потому что внутри 12345678910111213 есть число от 1 до 12.

/^\d{1,12}$/

Вариант "идеоматичный":
1. Эта библиотека должна экспортировать функции с сишным abi (extern "C")
2. В коде на C# ты описываешь эти функции при помощи pinvoke
3. Добавляешь в проект dll-ку с собранной сторонней либой.
Профит

Вариант "ситуативный и будет работать только на винде":
1. Берёшь C++/CLI
2. Делаешь на нём .Net библиотеку и делаешь нужное количество классов -обёрток над плюсовым кодом.
Профит

В случае с этой библиотекой можно ещё попробовать:
1. Найти альтернативы
2. Переписать на C#

Такое устройство называется "роутер с воткнутыми в него модемами и настроенным MPTCP".

https://www.openmptcprouter.com/

Вы наверное хотите скрыть не сам 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