Созданные коммиты уничтожаются и записываются новые.
Если вы всегда "на стреме" и записываете хеш аварийного коммита
За исключением ситуации, когда прошло время и неиспользуемые коммиты git уже вычистилМне трудно представить такую ситуацию, что через месяц захочется покопаться в мусоре и снова пересобрать старые косяки. Обычно проблемы видны сразу.
все это, запрещают делать в важных ветках, где нужен контроль версий.Контроль версий происходит во всех ветках. А важные мы защищаем от удаления.
а сам факт уничтожения истории в системе контроля версий порождает вопрос, а зачем тогда вообще контроль версий?
если чтото не так смержили при ребейзе выковыривать придется из удаленных
ребейз не применим, если вы не один пользуетесь веткой. А если один, то всё на вашей совести
1. Не надо использовать расшаренную папку в качестве репозитория
любой сервер на linux, к которому можно подключиться по ssh
Получу отдельную ветку для m.txt
как вернуть все как было с учетом того что я не могу изменять этот код.
-git commit --amend --no-edit + git rebase --continue
то не связано с тем что некоторые коммиты стали пустыми и были удалены
Вы путаете хранилище и указатель. Ветка в Git — не сейф, а стрелка на коммит. При rebase вы двигаете стрелку, а не трогаете объекты. Коммиты остаются в базе — те же SHA-1, те же данные.
«Витрина» — это метафора для текущей истории ветки. Если вам нужен «архив всех опечаток» — Git его хранит. Но показывать его в основной истории — всё равно что выставлять в музее черновики с зачёркнутыми словами вместо финальной рукописи.
Если для вас история проекта — «картинка», то вы явно не пишете код, а коллекционируете артефакты. Для разработчиков rebase — не косметика, а хирургия:
Потому что ветка — ярлык, а не склад. Коммиты никуда не деваются: reflog и object database всё помнят.
Если вам так дороги все промежуточные состояния — вешайте на них теги. Git не запрещает коллекционировать «исторические раритеты». Но требовать, чтобы основная ветка была складом черновиков, — это не контроль версий, а страх отпустить прошлое.
Git — это инструмент для управления историей, а не для её мумификации. Если вам нужно, чтобы каждый коммит был «неприкасаемым артефактом», — да, Git вам не подходит.
Но тогда, может, вам стоит перейти на Mercurial? Он как раз для тех, кто боится переставлять стрелки и верит, что «история должна оставаться такой, какой её написали в первый раз». Git управляет историей. Mercurial её хранит. Поэтому одни делают релизы, а другие пишут манифесты о «неприкасаемости коммитов».
Мы же продолжим работать с инструментом, который позволяет делать историю полезной, а не просто «честной».