Sly_tom_cat .

Для синхронизации между двумя компами использую syncthing.
git и github (как remote master) используется именно для осмысленных коммитов с законченными доработками.
Так у меня чистая история коммитов, ни ребейзов ни прочей сомнительной активности для приведения истории в порядок - не нужны.

Но это не отменяет использования веток. Отдельная фича - отдельная ветка. Почти рабочее - мержу в dev. После тестирования меджу dev в master. В мастер стараюсь напрямую не коммитить, разве что какие-то обновления readme и прочей атрибутики.

В master лежит код в котором я уверен, что он рабочий ибо мастер иногда качают (проект не требует сборки т.к. на питне и баше и легко ставится из исходников).

Когда вполне созрела версия - создаю релиз (прямо на github-е) ну попутно лью в PPA на launcpad (это уже собственно к разработке не имеет отношения - это автоматическая доставка обновлений пользователям).

Скомпроментировать сервер можно по разному.

Если на сервере получили удаленно рута то вам ничего не поможет получить с сервера все что на нем размещено.

И решать такие вопросы нужно не на уровне прикладного софта (к которому относится GIT), а на уровне защиты самого сервера от угроз. Иными словами нужно не о шифровании в гите думать, а о том как защитить сервер от компроментации.

На мой взгляд, вопрос болше "политический". чем технический.

Версии поддерживаемые нужно четко отделить от не поддерживаемых.
Так к примеру есть у меня проектик на питоне, и был он изначально на Python v2.7, но в какой-то момент меня достала "поддержка" юникода во втором питоне. Переполз на 3-й, но т.к. на некоторых платформах есть проблемы с отдельными библиотеками для третьего питона ветку со вторым питоном я отделил и объявил - "для ветки второго питона - только хотфиксы".
Ветка третьего питона уже так далеко ушла от второго, так что там фиксы для второго один в один просто не подойдут уже. Т.е. один и тот же код фикса я просто уже не могу влить в обе ветки (там в третьем питоне весь код уже переделан на ООП, а во втором - там чисто процедурный подход).

Вот примерно так я вижу и вашу ситуацию. Если люди хотят фикс в старой версии - то ваше право сделать одно из двух:
1. Отказать, сказав что старая версия более не поддерживается,
2. Сделать фикс в старую версию и отдельно сделать фикс в новую (вполне возможно что один в один код для фикса в новой может отличаться от фикса в струю)

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

Ну вам же черным по английски пишут: мердж затрет вам толпу файлов (не отслеживаемых).

У меня дома и на работе настроена синхронизация каталогов через облако (yandex и google).
Внутри синхронизируемого каталога у меня локальные git репозитории.

Очень удобно - на работе поделал что-то и в любой момент сорвался (можно даже ничего не коммитить, не то что pull-ить) и поехал домой - дома продолжаешь ровно с того момента где закончил на работе.

Тут была уже тема, где долго спорили, что облако в такой ситуации не нужно, все решается пуллом в глобальный репозиторий. Но мне удобнее с облаком, а git я использую именно и только для контроля изменений и версий.

Не понятно в чем вопрос?
Ну есть у меня master, dev (ушедший от мастера вперед на несколько коммитов), и bug#48 (ушедший от dev на пару коммитов). Если мне нужен фикс из bug#48 в dev так я промерджу bug#48 в dev. В чем сложность и к чему тут ребейз?

Делаете форк, и работаете с ним независимо, оригинальный держите в другой копии. Переключаетесь через git checkout.

Даже не совсем понял в чем собственно вопрос....