«Галочка» на КДПВ ужасна. Её сделал какой-то таджик, который пишет справа-налево: она отражена зеркально относительно нормального направления письма. Попробуйте написать галочку от руки, у вас наверняка завершающий — правый — росчерк будет более «размашистым».
Ну так Option и есть такая «пометка для компилятора о том, что (не) может быть null». Только отслеживается это на уровне системы типов. А в виде оператора ".?" это больше похоже на костыль.
править историю в хвост и в гриву без оглядки на коллег и чтобы вам за это ничего не было
Кто вам такое сказал? Я постоянно пользуюсь git rebase, каждый день раз по пять, как практически все мои коллеги. При должном опыте, практике и соблюдении элементарных правил безопасности, это совершенно нормально и безопасно. Правила просты: ребейзить только свои локальные ветки, не ребейзить общие ветки (master, develop) без согласования со всей командой, если опубликовал фичеветку ребейзить можно только если над фичей работаешь только ты, если кто-то ещё — согласовывать ребейзы с этим коллегой. Всё, всё просто, никаких проблем. Именно что, с оглядкой на коллег, чтобы ничего за это не было. Мне ли вам объяснять, что гит — это инструмент, со своими опасностями, как фрезерный станок: если сувать руки внутрь, то может оторвать, но если правильно пользоваться — можно это делать совершенно безопасно годами. Тут есть момент, что инструмент для команды коллективный, да. Но при ошибках работы с ним никто не умирает, в отличие от ошибок с коллектиным оружием (если кто-то один накосячит, например, с миномётом, разорвёт весь взвод).
Ну в гите можно накостылять с ветками, то есть вместо того, чтобы ребейзить одну и ту же ветку, делать git checkout -b feature-v2 feature && git rebase master; git checkout -b feature-v3 feature && git rebase master итд. При желании можно это всё завернуть в красивый плагин (похожее сделали с git-stash) и счастливо пользоваться, но как-то никогда не нужна была такая функциональность. Хотя может быть, если бы была, ей бы и пользовались, хз. Как вы сами, часть пользуетесь hg evolve? Интересен реальный опыт.
Всё это, само собой, имеет для вас смысл, если вы заботитесь о чистоте истории так же, как о чистоте кода. Если вам всё равно, и вы считаете, что чистая история никому не нужно, то ребейз не для вас.
Применений много. Например, вы накоммитили в локальную ветку кучу коммитов, включая коммиты виды «сделал фичу а», «сделал фичу б», «ой, забыл запятую в фиче a», «починил фичу б», «фича б поломала фичу а, починил её», «отрефакторил фичу б». Никому не интересно в истории видеть все ваши метания с запятыми, фиксами и правкой пробелов. Ребейз позволяет такую историю ужать до «сделал фичу а», «сделал фичу б» и отдать ветку в мир с двумя аккурантыми коммитами.
Другой пример: у вас ветка следит за мастером. Если постоянно вытягивать и мержить мастер в вашу фичеветку, в истории получается «колосок» из мержей, что 1) некрасиво, 2) после пуша только путает историю, т.к. никому неинтересно, когда и как вы подтягивали мастер, 3) добавляет лишний хаос, 4) эти мержи не несут смысловой нагрузки к вашей разработке, итд. Альтернатива: вытягивать master отдельно, а потом фичеветку ребейзить на него. Тогда, когда вы отдадите свою ветку в мир, он будет базироваться на актуальном мастере, история будет ровная, гладкая и шековистая^W^W.
Есть ещё несколько примеров, когда ребейз полезен, в том числе для исравления всяких ошибок и факапов. Я привёл самые частые случаю использования. Рекомендую всё же посмотреть презентацию Mark-а.
Почитал немного про changeset evolution, выглядит интересно. Как я понял, это как бы ведение истории изменения истории? Можете рассказать по подробнее простыми словами? В двух словах.
А вы не задумывались о том, что мерк, запрещая некоторые варианты поведения, запрещает их и тогда, когда это действие хотят сделать намеренно? Не хочу, чтобы молоток за меня решал, стоит мне бить по гвоздь сбоку или нет. А если кто-то попадает молотком по пальцам — то тоже молоток виноват? Ай-ай-ай, молоток позволил попасть себе по пальцам! Он должен быть с резиновой оправой и с направляющими, чтобы нельзя было бить по не по шляпке гвоздя! А простые молотки вообще запретить!
Извините, мне нравится мой простой тяжёлый железный молоток с удобной деревянной ручкой.
Никто не мешает делать точно так же в гите. Гитфлоу — это просто рекомендация из разряда «бест-практисис», набор паттернов ведения истории, если можно так сказать. На самом деле в чистом виде он не всегда удобен. В общем, в каждом проекте команда сама выбирает стратегию ветвления, и ваш вариант тоже вполне используется.
Да можно и опубликовать свою ветку, если, что, при условии, что ты уверен, что никто из команды не будет её трогать. Тогда можно будет её потом вытянуть, скажем, на домашнем компе, поправить, отребейзить и запушить с форсом обратно. Гит даёт редкостную свободу, но любая свобода подразумевает ответственность.
К меркуриалу у меня в этом плане есть претензия. Тут много говорилось, что он не даёт многое делать. Ужасно не люблю, когда мне что-то не дают делать. Не люблю системы, которые умнее меня и лучше знают, что куда мне можно лезть, а куда нет.
Но как тогда быть точно уверенным, что код после мержа попал в основную ветку из истории основной ветки, а не из смерженной (или наоборот)? Всё равно в этот момент связть веток с кодом теряется, и без отслеживания по истории такие вещи не понять, как и в гите. Так что получается избыточная сложность, которая не особо облегчает поиск.
Вот с этого момента поподробнее. Вот я мержу две ветки, соответственно создаётся новый мерж-коммит с двумя родителями. Внимание, вопрос: какой ветке будет принадлежать этот мерж коммит? Или в меркуриале всё не так, и мерж коммитов нет? Вроде помню, что были, но могу ошибаться, т.к. давно с ним не работал. Мне и правда интересно, вопрос без сарказма.
Ну так это тогда две разные сущности, сделанные для совершенно разных целей и с разной идеологией. Говорить, что одна из них — полноценные ветки, а вторая — нет, это как говорить, что мерседес — настоящая машина, а мазда — нет. Холиварно, не продуктивно и просто неправильно.
Вы сейчас какие-то небылицы рассказываете. Чтоб были понятно — у меня 15 лет стажа после универа, лет 5 на гите, писал профессионально на перле, пхп, питоне, теперь на скале пишу. Команды были от 2-3, до 15 человек, сейчас пишем большой командой суровый энтерпрайз: скала, хадуп, бигдата, все дела. С описанными проблемами не сталкивался никогда. Или просто за проблемы их не считал.
Вы меня не слушали. Да, снепшоты он делает, и делает он это для отслеживания *изменений*, хотя лучше здесь сказать *содержимого*? Ведь данные он хранит в блобах (не связанных напрямую с именем оригинальных файлов, если быть педантом — имена хранятся рядом, в деревьях). И сжимает блобы, как было уже указано выше, дельта-компрессией. И всё это сделано, чтобы следить за изменением содержимого. Блин, ну не было у меня никогда проблем с переименованием файлов в гите, не было. И если файл при переименовании изменился больше, чем на 50%, то действительно ли это старый файл? Ну какая мне разница, что файл был переименован, если он настолько изменён, что по сути это другой файл? Ещё раз: мне не важно где какой файл как называется, мне важно, оттуда какой кусок купола взялся. И гит решает эту проблему идеологическую. А блобы там и деревья — это деталь реализации, и она меня редко волнует. А учитывая популярность гита, я не один такой. Так что может пора просто изменить точку зрения на нашу программисткую реальность, и понять, что мы создаём не файлы, а текст, код, содержимое?
Кто вам такое сказал? Я постоянно пользуюсь git rebase, каждый день раз по пять, как практически все мои коллеги. При должном опыте, практике и соблюдении элементарных правил безопасности, это совершенно нормально и безопасно. Правила просты: ребейзить только свои локальные ветки, не ребейзить общие ветки (master, develop) без согласования со всей командой, если опубликовал фичеветку ребейзить можно только если над фичей работаешь только ты, если кто-то ещё — согласовывать ребейзы с этим коллегой. Всё, всё просто, никаких проблем. Именно что, с оглядкой на коллег, чтобы ничего за это не было. Мне ли вам объяснять, что гит — это инструмент, со своими опасностями, как фрезерный станок: если сувать руки внутрь, то может оторвать, но если правильно пользоваться — можно это делать совершенно безопасно годами. Тут есть момент, что инструмент для команды коллективный, да. Но при ошибках работы с ним никто не умирает, в отличие от ошибок с коллектиным оружием (если кто-то один накосячит, например, с миномётом, разорвёт весь взвод).
Она многое объясняет.
Применений много. Например, вы накоммитили в локальную ветку кучу коммитов, включая коммиты виды «сделал фичу а», «сделал фичу б», «ой, забыл запятую в фиче a», «починил фичу б», «фича б поломала фичу а, починил её», «отрефакторил фичу б». Никому не интересно в истории видеть все ваши метания с запятыми, фиксами и правкой пробелов. Ребейз позволяет такую историю ужать до «сделал фичу а», «сделал фичу б» и отдать ветку в мир с двумя аккурантыми коммитами.
Другой пример: у вас ветка следит за мастером. Если постоянно вытягивать и мержить мастер в вашу фичеветку, в истории получается «колосок» из мержей, что 1) некрасиво, 2) после пуша только путает историю, т.к. никому неинтересно, когда и как вы подтягивали мастер, 3) добавляет лишний хаос, 4) эти мержи не несут смысловой нагрузки к вашей разработке, итд. Альтернатива: вытягивать master отдельно, а потом фичеветку ребейзить на него. Тогда, когда вы отдадите свою ветку в мир, он будет базироваться на актуальном мастере, история будет ровная, гладкая и шековистая^W^W.
Есть ещё несколько примеров, когда ребейз полезен, в том числе для исравления всяких ошибок и факапов. Я привёл самые частые случаю использования. Рекомендую всё же посмотреть презентацию Mark-а.
Извините, мне нравится мой простой тяжёлый железный молоток с удобной деревянной ручкой.
то есть то, что в гит есть из коробки, в мерке мне нужно ставить плагин, который к тому же ещё и в бете?
К меркуриалу у меня в этом плане есть претензия. Тут много говорилось, что он не даёт многое делать. Ужасно не люблю, когда мне что-то не дают делать. Не люблю системы, которые умнее меня и лучше знают, что куда мне можно лезть, а куда нет.