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

Кривая обучения популярных текстовых редакторов

Каеф!

Странно что тут нет vi и сколько можно насиловать картинку про DF?)

Просто расскажу про свой сетап:
1. Markdown на очень высоком уровне. Умеет ходить по ссылкам, понимает некоторые диалекты. Умеет в подсветку синтаксиса примеров кода прямо не отходя от кассы.
2. Статический анализ: flycheck, позволяет подключать десятки внешних средств статического анализа и проверять всё на лету.
3. YAML: есть специальный режим, и да, тоже с проверкой синтаксиса. Да, снова Flycheck.
4. Protobuf: и такой режим есть, подсвечивает синтаксис, вот это всё.
5. RST из коробки.
6. Shell-Script: есть плагин, который и синтаксис проверит, и форматирование сделает.
Кстати, подо все языки, которые встречаются в тексте, поставил средства автоформата, что позволило вывести планку качества на новый уровень. То есть пишу я Markdown, понадобилось вставить листинг на PHP. Вставил, тут же открыл в новом буфере этот текст, отформатировал beautish'ем или чем там PHP форматируют, вернулся обратно, а всё уже круто.
Настроил, кстати, интеграцию с Terraform. Примеры кода форматировать можно тоже, режим умеет вызывать terraform fmt к фрагменту кода, который надо поправить.
Про всякие там SQL, Python, Bash вообще не вижу смысла упоминать.

Коллеги, а есть ли у вас опыт приучения менеджеров/не айтишников работе с гитом/маркдауном?

Как думаете, какой тулинг для такого случая лучше подобрать? )

Сейчас мучаюсь выбором очень простого гит-клиента под эту ситуацию. В качестве редактора думаю попробовать "продать" им Obsidian.

кнут, кандалы, хлеб и вода
а не
премия, барбер-шоп, вейп

я бы не выходил за пределы встроенного браузерного редактора в GitHub/GitLab

а то во всех остальных тулзах придется рассказывать про коммиты, пуши и прочее, «а оно вам надо?» (с)

эти редакторы хорошо скрывают лишние абстракции, типа того же коммита

а как потом объяснять бранчи?

и, туда их, мерж реквесты?

ну тут Игорю стоит объяснить планируемые use-cases использования всего этого дела

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

Я пока что в раздумьях. Сотрудники будут корректировать архитектурные схемы (предполагаю тащить их в plantuml/mermaid) и описания. И для того, чтобы потом найти хвосты — аккуратные коммиты и связка с тикетами выглядит необходимыми

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

Если людям платят, почему бы не потребовать от них обучиться процедуре?  Она не сложная.

Юзер должен выучить процедуру commit, push.  Для коммита можно попросту назначить какую-нибудь клавишу, типа F5.  Нужно также знать, куда нажать, чтобы посмотреть статус.  Так что процедура commit, push автоматизируется.  Все мержи могут делать более опытные люди.  Не автоматизируются pull и branch (необязательно нужен).  Я изучал действия с git «потому что надо», и все делают так, и особых навыков для этого не нужно.  При этом «гит в командной строке» никогда не изучал и не горю желанием, все через magit.vc

GNU Emacs сочетает в себе редактор и git-клиент magit.vc — высокого качества, разрабатывался в т.ч. за деньги.  Можно сделать сборку, настроенную под конкретные узкие нужды проекта для конечных юзеров.  Я отдаленно слышал, что так делают, но сам не пробовал.

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

инструкцию-памятку 😂 не более чем на 10 строк, прям с прописанными путями и примером именования коммита