Минус ему, а не плюс. Если уж мы говорим о чисто алгоритмическом решении — сортировка даст нам асимптотику в O(N*logN), тогда как решение на хеш-таблицах — O(N). А уж определение эффективности алгоритма по количеству сравнений — уж извините, закрадывает некоторые сомнения в квалификации собеседующего.
В большинстве случаев описанные ситуации вылавливаются на этапе запуска тестов после ребейза. Не компилируется или тесты упали — ищем проблему и применяем один из описанных подходов (наиболее подходящий под наш workflow).
Описанное в посте как минимум поймается после пункта 3) из вашего списка, а потому если в полиси сказано «хотим компилируемых коммитов» — Васю таки надо увольнять. В чем тут вина ребейза — все еще не вижу.
И мне ну очень сложно представить ситуацию в реальном проекте, когда не было конфликтов, код компилируется, тесты проходят, но проблема была. И (глубокое ИМХО, разумеется) в реальной жизни такими ситуациями (когда со стремящейся к нулю вероятностью у нас в дереве будет пара некомпилируемых коммитов) можно смело пренебречь.
Повторюсь: вы взяли гипотетическую и совершенно дурацкую ситуацию (либо с криворуким Васей, либо с несогласованным workflow) — и сделали из нее далеко идущие обобщающие выводы о вредности или полезности отдельных компонентов гита. А на самом деле вина гита тут только лишь в том, что он предоставляет слишком хорошие прицельные приспособления, которыми так удобно целиться себе в ногу.
Гит гибок — и прибивать гвоздями методики совершенно необязательно. Из чтения ваших постов про гит может сложиться впечатление, что возможны только два варианта — всегда плохой ребейз и всегда хороший мерж. А это не так.
У нас есть как минимум 4 одинаково (в зависимости от того, чего конкретно мы хотим) хороших варианта:
— откатить ребейз и сделать обычный мерж;
— откатить коммиты в ветке через reset --soft и собрать ветку заново (как делают разработчики того же Линукса);
— сделать как написано выше+реордер коммитов, чтобы фикс-коммит утащить вниз (если изменения не глобальные — это возможно);
— забить на некомпилируемость и сделать просто как написано в предыдущем комменте — ибо, например, в кровавом энтерпрайзе бисект ни на фиг не нужен.
Выбор подходящего варианта для каждого конкретного случая позволит нам иметь историю ровно такую, какую мы хотим.
А оба ваших поста про гит, уж извините — популизм, пагубно влияющий на умы начинающих гитоводов. К тому же — с подменой тезиса: плохая линеаризованная история (что правда)=плохой ребейз (что неправда).
Все просто: rebase — хорошо, линеаризация истории — плохо.
В этом случае Васе нужно было:
— сделать rebase ветки на мастер
— пофиксить конфликты в отдельном коммите (если изменения API глобальные — возможно, сделать реордер коммитов для наглядности)
— сделать merge --no-ff в мастер
Не хватает кармы чтобы картинку запостить, но выглядеть это будет примерно так:
|
o
| \
| o
| /
o
|
Справа — коммиты Васи в отдельной ветке.
Да, это все еще требует больше усилий, чем банальный мерж, но в результате историю можно эффективно просматривать без «специализированных инструментов» — и сразу видно, какие коммиты суть отдельная фича, и дифф цельной фичи (=мерж коммит) можно увидеть в 2 клика.
Вроде обещают (пруфлинка не дам) доставку не просто сообщений чятика, но даже досылку фоточек и видеоклипчиков. Хотя вполне возможно, что имеется в виду офлайн второго собеседника (т.е. функциональность серверная, не клиентская)
Такое может быть, если не задумываться об атомарных изменениях. Да, для этого нужно изменить подход к программированию, разбивать на мелкие задачи и фокусироваться на них.
Это отличное правило в вакууме. В реальности бывают ситуации, когда рефакторинг на проекте в полмиллиона строк кода пару дней вообще не компилируется, а потом еще неделю тесты падают.
Писать, что изменена такая-то константа. Можно еще добавить — зачем.
Т.е. тратить на коммит месседж больше времени, чем на собственно изменения из этого коммита?
Вот. Подобное мышление — это уже следствие того, что редактирование истории становится частью рабочего процесса.
Это как раз наименее строгая из претензий. Большинство пользователей гита занимаются причесыванием истории на уровне веток, а не на уровне коммитов, и это вполне ОК. Просто в некоторых ситуациях затраты времени на причесывание коммитов экономят время на ревью и тогда они оправданы.
Лично я люблю гит именно за то, что он позволяет стрелять из сотен видов оружия и в тысячи разных точек на ноге.
Если branch.autosetuprebase не стоит (или pull делается без ключика --rebase), то мы получим наихудший вариант из возможных (с которым я долго и не всегда успешно борюсь в своих проектах) — origin/master будет смержен в локальный master, а значит бранч тэг перескочит на соседнюю ветку и история станет менее читабельной (мастер больше не будет идти ровно).
Если пулл сделан с ребейзом — по факту ничем не отличается от приведенного в топике кейса.
Условие «делать коммит законченным» мешает коммитить часто, и местами — мешает сильно. Бывают моменты, когда в коде натуральные КРОВЬ КИШКИ РАСЧЛЕНЕНКА на протяжении целого дня, а то и нескольких. Следуя вашим правилам — в таком случае разработчику остается уповать только на историю, которую хранит ИДЕ (если хранит).
Условие «писать содержательное сообщение» несколько противоречит правилу «коммитить часто» — ну в самом деле, что мне написать в коммит месседж, когда я переключаю контекст, а из текущих изменений — одна измененная константа, скажем?
Плюс к этому правило «коммитить часто» порождает множество коммитов на каждую мелкую фичу, которые сильно захламляют историю. Я это в полный рост наблюдаю сейчас, когда перетянул последний проект на гит с свна и в силу недостатка опыта у народа с гитом мы пока придерживаемся самых элементарных гайдлайнов.
Такая, что при ребейзе коммитером конфликты мержит коммитер, а при мерже мейнтейнером конфликты придется мержить мейнтейнеру, а это явно не его забота. Ему нужно проревьювить ченжи не в вакууме, а относительно актуального хеда.
А как иначе — не коммитить «потому что некрасиво»? Нет уж, пусть лучше локально будет некрасиво, зато я в любой момент времени смогу проследить историю дебага без извращений.
> Аналитики агенства оценивают переход… от 1274$ до 2069$ на один десктоп.
Откуда такие суммы? Полностью новая машина (без монитора) с лицензией войдет в $500 со свистом (если не дешевле — на таких-то объемах), причем нужна она далеко не всегда. Получается, остальное — на инфраструктуру. Я, конечно, не МС-админ, но мне представляются сомнительными инфраструктурные затраты в 1.5к на рабочку при апдейте версии ОС.
Были б это наши аналитики — я бы сказал, что попахивает попилингом.
Вы меня извините, интерфейс IDEA просто отличный. Красивые и информативные иконки, выверенные элементы интерфейса… Оставшийся в прошлом веке XCode на его фоне смотрится динозавром.
Почти 3000 символов и 5 скриншотов, чтобы объяснить пользователям хабра(!) в хабе для разработчиков(!!!), как сделать элементарное однокликовое действие. Круто.
Действительно, ребейз теряет контекст и об этом нужно помнить (хотя это в большинстве случаев и не важно).
Описанное в посте как минимум поймается после пункта 3) из вашего списка, а потому если в полиси сказано «хотим компилируемых коммитов» — Васю таки надо увольнять. В чем тут вина ребейза — все еще не вижу.
И мне ну очень сложно представить ситуацию в реальном проекте, когда не было конфликтов, код компилируется, тесты проходят, но проблема была. И (глубокое ИМХО, разумеется) в реальной жизни такими ситуациями (когда со стремящейся к нулю вероятностью у нас в дереве будет пара некомпилируемых коммитов) можно смело пренебречь.
Повторюсь: вы взяли гипотетическую и совершенно дурацкую ситуацию (либо с криворуким Васей, либо с несогласованным workflow) — и сделали из нее далеко идущие обобщающие выводы о вредности или полезности отдельных компонентов гита. А на самом деле вина гита тут только лишь в том, что он предоставляет слишком хорошие прицельные приспособления, которыми так удобно целиться себе в ногу.
У нас есть как минимум 4 одинаково (в зависимости от того, чего конкретно мы хотим) хороших варианта:
— откатить ребейз и сделать обычный мерж;
— откатить коммиты в ветке через reset --soft и собрать ветку заново (как делают разработчики того же Линукса);
— сделать как написано выше+реордер коммитов, чтобы фикс-коммит утащить вниз (если изменения не глобальные — это возможно);
— забить на некомпилируемость и сделать просто как написано в предыдущем комменте — ибо, например, в кровавом энтерпрайзе бисект ни на фиг не нужен.
Выбор подходящего варианта для каждого конкретного случая позволит нам иметь историю ровно такую, какую мы хотим.
А оба ваших поста про гит, уж извините — популизм, пагубно влияющий на умы начинающих гитоводов. К тому же — с подменой тезиса: плохая линеаризованная история (что правда)=плохой ребейз (что неправда).
В этом случае Васе нужно было:
— сделать rebase ветки на мастер
— пофиксить конфликты в отдельном коммите (если изменения API глобальные — возможно, сделать реордер коммитов для наглядности)
— сделать merge --no-ff в мастер
Не хватает кармы чтобы картинку запостить, но выглядеть это будет примерно так:
|
o
| \
| o
| /
o
|
Справа — коммиты Васи в отдельной ветке.
Да, это все еще требует больше усилий, чем банальный мерж, но в результате историю можно эффективно просматривать без «специализированных инструментов» — и сразу видно, какие коммиты суть отдельная фича, и дифф цельной фичи (=мерж коммит) можно увидеть в 2 клика.
Это отличное правило в вакууме. В реальности бывают ситуации, когда рефакторинг на проекте в полмиллиона строк кода пару дней вообще не компилируется, а потом еще неделю тесты падают.
Т.е. тратить на коммит месседж больше времени, чем на собственно изменения из этого коммита?
Это как раз наименее строгая из претензий. Большинство пользователей гита занимаются причесыванием истории на уровне веток, а не на уровне коммитов, и это вполне ОК. Просто в некоторых ситуациях затраты времени на причесывание коммитов экономят время на ревью и тогда они оправданы.
Лично я люблю гит именно за то, что он позволяет стрелять из сотен видов оружия и в тысячи разных точек на ноге.
Если пулл сделан с ребейзом — по факту ничем не отличается от приведенного в топике кейса.
Условие «писать содержательное сообщение» несколько противоречит правилу «коммитить часто» — ну в самом деле, что мне написать в коммит месседж, когда я переключаю контекст, а из текущих изменений — одна измененная константа, скажем?
Плюс к этому правило «коммитить часто» порождает множество коммитов на каждую мелкую фичу, которые сильно захламляют историю. Я это в полный рост наблюдаю сейчас, когда перетянул последний проект на гит с свна и в силу недостатка опыта у народа с гитом мы пока придерживаемся самых элементарных гайдлайнов.
Откуда такие суммы? Полностью новая машина (без монитора) с лицензией войдет в $500 со свистом (если не дешевле — на таких-то объемах), причем нужна она далеко не всегда. Получается, остальное — на инфраструктуру. Я, конечно, не МС-админ, но мне представляются сомнительными инфраструктурные затраты в 1.5к на рабочку при апдейте версии ОС.
Были б это наши аналитики — я бы сказал, что попахивает попилингом.
Извините — не удержался.