Gregory's ServerО том, как НЕ надо переименовывать master в main
https://gitlab.freedesktop.org/monado/demos/openxr-simple-playground/-/commit/2ebebe8f68af422222321d2cdca52aa12773bc71
(прошу прощения за ссылку на фронтенд гитлаба, гитлаб - это то, как НЕ НАДО хостить код)
Вместо того, чтобы просто молча переименовать ветку, создали новую ветку main и сделали её дефолтной, а master не удалили. Мало того, закинули туда коммит, упоминающий о смене ветки в Readme. Да ещё и закинули этот коммит только в master, в main он не попал.
Что сдесь не так? Разработчик, делающий git pull получает вместо обнолённой ветки main или ошибки просто незаметный коммит и ДАЖЕ НЕ ЗАМЕЧАЕТ что получил неактуальный код, мало того, дата последнего коммита не такая уж старая.
Мало того, дальше он ребейзит свои коммиты поверх, потом он не сможет нормально сделать rebase на main т.к помимо своих коммитов в ребейз попадёт и коммит с изменением readme.
Если бы ветку просто переименовали, а старую удалили, такого бы не было.
Если бы ещё и закинули коммит в новую - это отразило бы момент изменения ветки в истории. Но в итоге всё получилось наоборот.
Не, я понимаю, может не нравиться слово, может захотелорсь сменить дефолт бранч. НО СДЕЛАЙ ЭТО, БЛИН, НОРМАЛЬНО!!!
#master #slave #mistress #мастеринг #main #git #бомбит
@ru
@rf
 3 comments
 @mittorn Мда, это гитлаб и гитхаб мозга — не понимать, как гит и базовые коллективы работают. Именно, что на стороне клонирующих не должно быть таких нюансов: свежак должен появляться по git clone ветки по умолчанию или хотя бы develop. Зачем им второй main, ё моё? |
@mittorn
Люди делают важное дело, а ты доёбываешься!
P.S. Можно сделать интерактивный ребейз и выкинуть коммит. Но это так, заметка, а не оправдание решения.