На работе мы имеем дело c git и github. Чтобы не захламлять историю нашего основного репозитория на гитхабе, мы решили соединять коммиты перед пулл-реквестом.
То есть вместо истории:
9fc47c08e9d70cdd33768eff1dd0c4ea95c95a7f Создал класс для фичи
69e87e4eee9bc656184a8e32c619625db0b2f51f Написал класс этой фичи
4644b4d8111fd6a9fb38087bfa9f869215ff842e Правлю баг…
4881c35c6d58e0453e737a06ae19d264acddf423 Правлю другой баг…
86861e363530a4924217e4a497a74b168beb157d Форматирование!
9680a87d2a86bb205615afeb6a9780fc7a914ef5 Все, теперь можно!
Мы получаем нечто вроде:
38b34074eb416155167b10c6914c95ee4c26d2e6 Фича такая-то. Описание особенностей.
Понятно, что так история выглядит намного приличнее и понятнее. Собственно, добиться этого просто. Разумеется, работа ведется в отдельной ветке (а то и форке). Изменения вносятся, коммитятся и, наконец, пушатся. А в какой-то момент задача полностью готова и хочется склеить коммиты.
Сначала мы сбрасываем текущее состояние до последнего общего с мастером коммита:
git reset --soft 3a1829e5f8d49cdc404df070133e5a64ccacdac2
Мы делали “мягкий” сброс, поэтому все наши изменения остались в коде, теперь мы должны из закоммитить:
git commit -a -m 'Message'
И, наконец, запушить новый коммит. Если не сделать –force, то это закончится неудачей.
git push --forсe
У способа есть минус — на деле эти ревизии сохраняются и их можно увидеть, посмотрев лог с указанием комиитов:
git log ff122876f2f5ad46b4c930a5889571e8b6db6913…c66b0cf61e269809e2d655f10fa0a6f2294da405