Ну «хак» — это не совсем то слово. Эти вещи документированы и имеют объяснение, и понять их можно. Я бы назвал это «стиль git» С переписыванием истории, с постоянной мыслью о том, какие коммиты опубликованы, а какие нет, и что можно делать, а что нельзя (и почему), с отрубленными головами (бесследно исчезающими при клонировании)… Я не прав или что-то упустил?

ИМХО, git-way это в некоторой степени UNIX-way к content-management’у. То есть ты можешь сделать именно так, как тебе кажется красивым и правильным. При этом что-то действительно красиво, а в чем-то ты просто криворукий извращенец. И нет никаких “внимание, этот каталог содержит системные файлы, вы уверены, что хотите его посмотреть?”.
И точно также, как и в вопросах администрирования или программирования, да хоть и как в вопросах обращения с болгаркой, без понимания что ты делаешь, зачем и какие тут есть грабли, тут непросто и шишек набить вполне придется.
Hg и bzr действительно более простые для новичков, но намного менее мощные инструменты. Вот только гит предлагает настолько много всяких мелких вкусностей, что разобравшись с ним, начинаешь его использовать очень много где.

По поводу стандартной модели – конечно, хотя некоторые подходы более git-way чем другие.

Поэтому приходится решать такие задачи:

Видимо, правильно будет запретить force на важных ветках на уровне pre-receive hook – подумаем над этим.

… этот локальный коммит можно будет заменить
или удалить.

При этом я думаю, что самый большой недостаток git, что ему труднее научить новых пользователей. Особенно если они непрограммисты. Потому что в случае git их надо учить не только принципам работы распределённой системы управления версиям, не только командному интерфейсу системы, но и постоянно указывать на грабли, которые для удобства и гибкости повсюду в ней лежат. И что hg, что bzr в этом отношении имеют огромное преимущество.

Впрочем, это исключительно личные преференции. Workflow очень хорошо и живо расписан.

Если понять git, то в дальнейшем он намного повышает эффективность работы. А понять в общем несложно – немного практики и всё.
А ничего опасного я с ним давно не встречал.

А git, всё-таки, обоюдоострый меч. Какое руководство ни возьми, обязательно будет предложено сделать что-то, что будет опасно для целостности данных или репозитория, или что потом придётся «расхлёбывать». Так и ходишь, как по минному полю