rebase, который не прописывается в историю. Сама идея rebase/squash/whatever хороша и иногда полезна, но это деструктивная команда, никак не отмечаемая в репозитории — ВДРУГ удалили часть коммитов бесследно. Это никак не соотносится с хранением истории проекта. Историю НЕЛЬЗЯ переписывать.
Ну и это ещё приводит к чудесным эффектам, когда такое делают у репозитория с которым кто-то уже синхронизировался. Что приводит к тому, что все “workflow” с использованием этих команд (тысячи их в интернете) неработоспособны когда одну и ту же фичу делают несколько человек или хотя бы один человек на нескольких рабочих местах (ноуте и рабочей станции или домашнем и рабочем компьютере). Но это уже побочные эффекты изначально кривого дизайна, заложенного в этих командах.
И вообще ребейз индивидуальная команда - сделал фичу один, ребейзнул и тд. Если над бранчем работает несколько человек то юзается бекмердж основного бранча а не ребейз.
reflog же. Хм. Читаю man — не вижу при чём он тут.
И вообще ребейз индивидуальная команда Это не важно. Важна сама штатная техническая возможность переписывать историю, никак не ограниченная вообще. Там хоть ACL'и нормальные появились? Или нет?
Вот если бы git сам при pull/push пользовался рефлогом (и там не было бы команды "expire") это было бы хоть на что-то похоже. А сейчас — push, ребейз, push — и репозиторий кровь кишки распидорасило а от git ни слова.
Я сам сторонник разрешения стрелять себе в ногу — но не когда речь идёт об истории, которая принципиально не должна редактироваться.
Ну гит не даст пушнуть если что-то распидорасит. Только через форс, а если ругатся на форс, то можно ругатся и на то что "rm -rf /" удалит вам все файлы в руте )
ИМХО возможность поправить историю хороша при факапе. Тогда рефлог позволяет очень гранулярно откатится куда надо и иметь чистую и читабельную историю, а не полный пиздец из-за одной ошибки.
ЗЫ: Кстати в компании мы не пользуемся рибейзом вообще, только мердж. Когда есть центральный репозиторий (гитхаб) в который feature branches регулярно пушатся, рибейз не нужен.
Ну гит не даст пушнуть если что-то распидорасит. Даст. Дабл-коммиты только так возникают если ребейзиться, пушить, снова ребейзхится и снова пушить. Что, подумав, не удивительно.
Я может туплю, но как? После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется? Если он там будет то дерево в локальном репозитории 1 ahead 1 behind и fast-forward не пройдет.
После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется? Да. А так как после второго рибейза того коммита уже нет, а есть новый (пусть и стем же сожержанием ПО СМЫСЛУ, но с другой чексуммой — т.е. идентификатором), то он снова проапушится и промёржится.
Воот! Я на это напоролся в первый же день — я использую свой сервер как точку встречи своих двух компов (итого на одного меня три репозитория — серверный и два на рабочих станциях, общение с апстримом через сервер) и, не подумав, сразу выбрал workflow с ребейзом. Потом уже подумал, хлопнул себя по лбу, и понял, что в такой схемек ребейз делать нельзя.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Это которой?
no subject
Это никак не соотносится с хранением истории проекта. Историю НЕЛЬЗЯ переписывать.
Ну и это ещё приводит к чудесным эффектам, когда такое делают у репозитория с которым кто-то уже синхронизировался. Что приводит к тому, что все “workflow” с использованием этих команд (тысячи их в интернете) неработоспособны когда одну и ту же фичу делают несколько человек или хотя бы один человек на нескольких рабочих местах (ноуте и рабочей станции или домашнем и рабочем компьютере). Но это уже побочные эффекты изначально кривого дизайна, заложенного в этих командах.
no subject
И вообще ребейз индивидуальная команда - сделал фичу один, ребейзнул и тд. Если над бранчем работает несколько человек то юзается бекмердж основного бранча а не ребейз.
no subject
Хм. Читаю man — не вижу при чём он тут.
И вообще ребейз индивидуальная команда
Это не важно. Важна сама штатная техническая возможность переписывать историю, никак не ограниченная вообще. Там хоть ACL'и нормальные появились? Или нет?
no subject
Я сам сторонник разрешения стрелять себе в ногу — но не когда речь идёт об истории, которая принципиально не должна редактироваться.
no subject
ИМХО возможность поправить историю хороша при факапе. Тогда рефлог позволяет очень гранулярно откатится куда надо и иметь чистую и читабельную историю, а не полный пиздец из-за одной ошибки.
ЗЫ: Кстати в компании мы не пользуемся рибейзом вообще, только мердж. Когда есть центральный репозиторий (гитхаб) в который feature branches регулярно пушатся, рибейз не нужен.
no subject
Даст. Дабл-коммиты только так возникают если ребейзиться, пушить, снова ребейзхится и снова пушить. Что, подумав, не удивительно.
no subject
no subject
Да. А так как после второго рибейза того коммита уже нет, а есть новый (пусть и стем же сожержанием ПО СМЫСЛУ, но с другой чексуммой — т.е. идентификатором), то он снова проапушится и промёржится.
У меня без всяких форсов получилось на раз-два.
no subject
no subject
no subject
Do not rebase commits that you have pushed to a public repository. (c)
а вообще торвальдс говноед ;]