Артур К.

Если у вас аккаунт организации - то там всё просто: На основной странице организации вкладка People, дальше слева выбираете либо Members либо Outside collaborators, там выбираете нужного человека и слева внизу будет кнопка "Remove from all repositories".

Если же у вас просто личный аккаунт - то там такого не предполагается (что естественно).

Возможно вам стоит рассмотреть вариант перевода вашего аккаунта в аккаунт организации (Settings -> Organisations -> Transform account) если по факту это всё равно организация. Конечно в этом случае поменяется схема биллинга, но GitHub недавно сильно снизил цены для GitHub for Teams так что вполне можно пользоваться.

Менеджер паролей KeePass.
В нем можно не только хранить учетные данные, но и вообще любые файлы, которые будут зашифрованы при прикреплении.

Т.к. у вас skip-name-resolve, то все имена хостов не резолвятся.
localhost - имя хоста. MySQL не может его отрезолвить для проверки прав доступа пользователя root@localhost.
У всех пользователей следует заменить хостнеймы на ip-адреса, напр:
root@127.0.0.1
Ни в базе, ни при авторизации не использовать хостнеймы.

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

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

Скажу так, я тоже занимаю веб разработкой, когда было модно (в 2010) - работал за 3мя мониторами!
Спустя время дошел до выгнутых широкоугольных и ограничивался одним, последним был вообще простой 27 Benq который с док станцией для новых макбуков! Но так как я его почти никогда не включал, только фильмы смотреть) Но сейчас "картинка в картинке" решает)

Сейчас работаю только за 15" макбуком и иногда екрана уже много) Изредка подумываю взять 13ку)
Дело привычки, благо mac OS удобна в использовании на одном екране (так как сколько бы мониторов у вас не было - всеравно взгляд падает на один, а в mac OS переход между рабочими областями (экранами) очень легко выполнить и не надо при этом головой крутить))

можно подключить к какому порту хочешь rx/tx от модуля блютуз, я подключил к D5(arduino)-Rx(AT-9) и D6(arduino)-Tx(AT-9), инициализация вот такая SoftwareSerial BTserial(6,5); я оставлю этот ответ может камута пригодится, я бы сэкономил несколько часов мучений :D

вы должны хоть что-то уметь, иначе будете ненужной обузой, а не рабом.

галеры - прекрасный способ для прокачки скилов. и технических, и социальных.