Какие ветки нужно сохранять на удалённом сервере?

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

<b>Первый вопрос:</b> Ветки, которые следует хранить на удалённом сервере.

В рамках Gitflow обычно рекомендуется хранить следующие ветки на удалённом сервере:

1. **master/main** - основная ветка, содержащая стабильные версии продукта. Для большинства проектов эта ветка должна всегда содержать код, который готов к развертыванию.

2. **develop** - ветка, в которой ведется основная разработка новых функций. Здесь происходит интеграция изменений от новых функциональных веток (feature branches).

3. **feature/*** - ветки, в которых разрабатываются новые функции. Они обычно создаются от ветки develop и по окончании работы сливаются обратно в develop. Хотя эти ветки не обязательно хранить на удалённом сервере (ведь они короткоживущие), некоторые команды предпочитают это делать для большей прозрачности процесса.

4. **release/*** - ветки для подготовки к релизу, где происходит финальная полировка и тестирование. Эти ветки тоже можно хранить на удалённом сервере.

5. **hotfix/*** - ветки, созданные для быстрого исправления критических ошибок. Эти ветки также могут быть полезны для хранения на удалённом сервере.

Таким образом, помимо главной ветки, следует хранить ветку develop, а также ветки release и hotfix, если они используются.

<b>Второй вопрос:</b> Ветки с обозначением версии (например, 2.3.X).

Ветки с обозначением версии, как в вашем примере, часто используются в рамках процедур управления версиями. Они могут служить для управления поддержкой и исправлениями для конкретных стабильных релизов, что может быть очень удобно в проектах с долгосрочной поддержкой (LTS). Эти ветки могут быть использованы, чтобы вносить исправления в старые версии ПО без необходимости сливать изменения в основную ветку разработки.

Такой подход может быть логичным для крупных проектов, где важно поддерживать несколько версий продукта одновременно. Например, если у вас есть версия 2.3.X, и вы хотите внести исправление в эту версию, вы можете создать ветку hotfix из 2.3.X, провести все необходимые изменения и затем слить их обратно в эту ветку.

Хранение нескольких версий может быть оправданным, если ваш проект предполагает работу с разными версиями, и пользователям нужны стабильные релизы с исправлениями. Это также делает систему более гибкой и удобной для пользователей, которым не всегда необходимо обновляться до самой последней версии.

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

Заливаются все ветки. Смотреть примеры каких то публичных реп смысла нет - потому что есть права доступа к веткам - вам видно то что разрешили. 
 Иначе не заливая как вы обеспечите например кодревью или мердж-реквесты? 
 Бывает что ветки после МР-ов удаляются - да, но далеко не всегда.

Первый вопрос: git - распределенная система контроля версий, предполагающая, что все ветки будут синхронизироваться с остальными участниками. Поэтому бояться хранить в удаленном репозитории какие-то "не те" ветки не стоит, единственное, что нужно обговаривать условия именований (например feature - ветки можно именовать по шаблону feature/{task_id}). Кроме того git flow предполагает наличие feature - веток, release, hotfix etc. поэтому ограничиваться в этом плане не стоит. 
 Второй вопрос: это ветки, в которых идет доработка предыдущих релизов. Например, если в версии 3.2.2 нашелся баг, то чтобы пользователи с версией 2.5.5 получили это исправление тоже, коммит с исправлением попадает и в ветку 3.2.х (и выпускается релиз версии 3.2.3) и в ветку 2.5.х (и выпускается релиз версии 2.5.6). Это опционально, кому-то просто удобно разрабатывать так, но вы можете выбрать то, как удобнее именно вам и вашей команде