Вводные данные: есть репозиторий, постоянные ветки master и devel, команда программистов и кучка веток-фич от каждого. Перед релизом фичи группируются в devel, правятся проблемы интеграции разных фич и результат уходит в master. В общем все как обычно.
Проблема: если при слиянии пользоваться merge --no-ff всё выглядит красиво, но удаление ветки не удаляет промежуточные коммиты. Имеется в виду, что графический инструмент типа gitg их отображает, оно и понятно, история как она есть. Но со временем репозиторий выглядит как запутаннейшая паутина. И удаление веток оставляет эту паутину как есть.
Другой способ - опция --squash которая сплющивает ветку до одного коммита и сажает его куда просили. После этого можно удалить ветку с ключом -D и все будет чисто. Но эта операция делает автором всех правок того, кто сквошил, а не того кто отращивал ветку. А еще это вводит в заблуждение - на графе ветка выглядит как не слитая.
Что нужно - красота на графе как при --no-ff и сплющивание при удалении ветки.
в рамках оффтопика - а зачем вообще изменять историю коммитов? мы вот специально перешли на меркуриал именно потому что в нем а) нет возможности удалить коммит б) в истории коммитов хранится к какой ветке он относится - очень удобно потом смотреть кто что когда делал
так вот в том то и дело, что мешает. В ситуации когда 10 программистов ведут 15 веток и постоянно сливаются друг с другом, чтобы иметь последние изменения до релиза получается спагетти-репозиторий. Ориентироваться в нем между двумя последними релизами ещё можно, память свежа, но потом это уже бесполезно. Ценность старых веток снижается. Для старой истории достаточно иметь devel где каждый коммит - одна большая модификация, подробнее просто не нужно.
Странный подход у вас, мержить между собой как хотят.
А что если вам использовать подход git-flow. master. от него develop. новые фичи от develop. фиксы багов от master. А между собой не давать им синхронизироваться. Все через develop.
У нас так работает все замечательно. Программистов больше 10 и веток обычно 1-2 активные, т.е. задачу сделали - слили в develop - закрыли. По 15 открытых никто не держит. Это дурдом.
Фича бранч->работа->ребейз на мейнлайн(если необходимо), сквош до одного коммита (автором)->codevreview, проверка на компиллируемость->автоматически мёрж в мейнлайн (при достаточном количестве голосов. Иначе, повторить).
Так и живём. Все счастливы :)
