Во многих тулзах для ревью по умолчанию отключен показ содержимого мерж коммитов. Я считаю это неправильным, но увы, «сверху» боятся ужесточать воркфлоу.
Реальная ситуация: делаем отдельный бранч А для большой фичи. В процессе разработки другая команда подготовила бранч Б с фичами которые нам нужны, но которые нельзя лить в мастер. Поэтому мы мержим себе бранч Б после код ревью. Девелопер, который нажимал кнопку «мерж» оказался не чистый на руку и в мерж коммит «Б в А» добавил вредоносный код. (Да да, человеческий фактор, который можно обойти качественным git workflow, либо утилитами наподобие той что в статье). Далее, бранч А готов к мержу в Мастер. И вот для этого код ревью не будет показан мерж коммит Б в А.
Самый простой способ этого избежать - отказ от мерж коммитов и работа исключительно через rebase+squash+cherry pick. Надеюсь, теперь вам моя мысль ясна :)
Как в прошлых полетах - могли бы взять Hasselblad. Только в этот раз его цифровую версию. Заодно могли бы проверить на устойчивость к космической радиации.
Они представили её на первое апреля. И, судя по оригинальному тексту, код этой CMS - это ии выхлоп. Новость нужно было начинать именно с этого.
The cost of building software has drastically decreased. We recently rebuilt Next.js in one week using AI coding agents. But for the past two months our agents have been working on an even more ambitious project: rebuilding the WordPress open source project from the ground up.
Меня в своё время посадили на rebase + fast forward ( + cherry pick при крайней необходимости). Merge коммиты запрещены на уровне репозитория. Правда делалось это изначально с другой целью - иметь чистую историю изменений, которая 1-в-1 берётся в качестве changelog при релизах.
Но тема статьи - очень большая боль. Часто у инженеров которые понимают эти проблемы (незаменимости некоторых) тупо не хватает мотивации переть против устоявшихся отношений. Тут часто, хоть и не всегда, большую роль играет психология.
Не понимаю минуса, но поясню. Я был на проекте, где был «незаменимый» лид и его друг сеньор. Так вот; аргументируя тормозами в разработке заставили лида написать комменты в коде (в данном конкретном случае хватило doxygen, без всяких конфлюенсов, но зато с версионированием) в тех местах где была слишком мудрёная логика и связь с внешними командами. Ну и еще некоторые шаги предприняли по денезаменимозации.
И далее вся команда нормально работала, правда лида потом попросили уйти по ряду других причин.
В svn можно было просто скопировать файлы из одного бранча в другой, без черри пика. У нас делали так же - вместо отдельных черри пиков вручную копировали некоторые файлы из одного бранча в другой (и называли это rebase, что в корне неверно). И когда пришла пора мержиться - вылезла куча однотипных конфликтов, которые вроде как тривиально может разрулить тот же beyond compare или araxis merge, но по факту все мерж конфликты пришлось проверять вручную, и вылезло немало расхождений.
Вместо того чтобы минусовать мой комментарий - советую изучить как именно гит хранит историю. В git это diff-ы, в svn - состояние целиком и полностью. Иначе локальная папка .git у вас в любом проекте была бы неимоверных размеров.
Git выстраивает «состояние проекта» целиком и полностью только в момент checkout. Это одна из причин, по которой git очень удобен для локальной разработки без необходимости обращения к серверу для каждой операции.
При этом Git хранит историю не как список отдельных правок в файлах, а как снимки состояния проекта (snapshots). Каждый коммит — это снимок того, как выглядели файлы в момент сохранения.
Вы (или ваш чатбот) git с SVN случайно не перепутали?
Никогда не нужно что-либо делать с системой контроля версий, если вы не понимаете что именно делаете. Вот прямо сейчас приходится разгребать мерж конфликты в двух ветках, которые разделились пару лет назад. «Всего» 650 конфликтных файлов, 90% из которых возникли потому что неправильно использовался git.
Ну так все, кроме разработчиков, будут рады. Особенно менеджеры. Чем не повод вернуть всех в офисы. /sarcasm
Но если по сабжу, то тут всё, как говорится, it depends. Впрочем, если компания настолько экономит что не может позволить себе минимальную инфраструктуру, то вряд ли она будет заморачиваться в целом. Возьмет первое что более-менее работает.
За гитхаб не подскажу, для активной разработки его в последний раз юзал лет 7 назад.
Во многих тулзах для ревью по умолчанию отключен показ содержимого мерж коммитов. Я считаю это неправильным, но увы, «сверху» боятся ужесточать воркфлоу.
Реальная ситуация: делаем отдельный бранч А для большой фичи. В процессе разработки другая команда подготовила бранч Б с фичами которые нам нужны, но которые нельзя лить в мастер. Поэтому мы мержим себе бранч Б после код ревью. Девелопер, который нажимал кнопку «мерж» оказался не чистый на руку и в мерж коммит «Б в А» добавил вредоносный код. (Да да, человеческий фактор, который можно обойти качественным git workflow, либо утилитами наподобие той что в статье). Далее, бранч А готов к мержу в Мастер. И вот для этого код ревью не будет показан мерж коммит Б в А.
Самый простой способ этого избежать - отказ от мерж коммитов и работа исключительно через rebase+squash+cherry pick. Надеюсь, теперь вам моя мысль ясна :)
Как в прошлых полетах - могли бы взять Hasselblad. Только в этот раз его цифровую версию. Заодно могли бы проверить на устойчивость к космической радиации.
Вы часто ревьювите именно мерж коммиты? Особенно если это вливание больших фичей. Статья ведь как раз об этом.
Так ничего не мешает в свою ветку намешать левых мерж коммитов из других веток. И если вкоммичтвание мерж коммитов явно не запрещено.
Они представили её на первое апреля. И, судя по оригинальному тексту, код этой CMS - это ии выхлоп. Новость нужно было начинать именно с этого.
Меня в своё время посадили на rebase + fast forward ( + cherry pick при крайней необходимости). Merge коммиты запрещены на уровне репозитория. Правда делалось это изначально с другой целью - иметь чистую историю изменений, которая 1-в-1 берётся в качестве changelog при релизах.
Не, я и не думал что минус от вас :)
Но тема статьи - очень большая боль. Часто у инженеров которые понимают эти проблемы (незаменимости некоторых) тупо не хватает мотивации переть против устоявшихся отношений. Тут часто, хоть и не всегда, большую роль играет психология.
Не понимаю минуса, но поясню. Я был на проекте, где был «незаменимый» лид и его друг сеньор. Так вот; аргументируя тормозами в разработке заставили лида написать комменты в коде (в данном конкретном случае хватило doxygen, без всяких конфлюенсов, но зато с версионированием) в тех местах где была слишком мудрёная логика и связь с внешними командами. Ну и еще некоторые шаги предприняли по денезаменимозации.
И далее вся команда нормально работала, правда лида потом попросили уйти по ряду других причин.
А в чём заключается школьная олимпиада по информатике с этим профилем (ИИ)?
От незаменимых не нужно избавляться. Нужно просто так выстраивать процессы чтобы незаменимые становились легко заменяемыми.
Вроде ещё не первое апреля.
Точно ли взлом происходит без участия пользователя? Или пользователю таки нужно перейти на специальную страницу в сафари?
В svn можно было просто скопировать файлы из одного бранча в другой, без черри пика. У нас делали так же - вместо отдельных черри пиков вручную копировали некоторые файлы из одного бранча в другой (и называли это rebase, что в корне неверно). И когда пришла пора мержиться - вылезла куча однотипных конфликтов, которые вроде как тривиально может разрулить тот же beyond compare или araxis merge, но по факту все мерж конфликты пришлось проверять вручную, и вылезло немало расхождений.
Вместо того чтобы минусовать мой комментарий - советую изучить как именно гит хранит историю. В git это diff-ы, в svn - состояние целиком и полностью. Иначе локальная папка .git у вас в любом проекте была бы неимоверных размеров.
Git выстраивает «состояние проекта» целиком и полностью только в момент checkout. Это одна из причин, по которой git очень удобен для локальной разработки без необходимости обращения к серверу для каждой операции.
Вы (или ваш чатбот) git с SVN случайно не перепутали?
Вот тут всё проще, компактнее и понятнее. Безо всякий «а если не прокатило, попробуйте». https://git-scm.com/cheat-sheet
Никогда не нужно что-либо делать с системой контроля версий, если вы не понимаете что именно делаете. Вот прямо сейчас приходится разгребать мерж конфликты в двух ветках, которые разделились пару лет назад. «Всего» 650 конфликтных файлов, 90% из которых возникли потому что неправильно использовался git.
Скажите, а обновлять существующий настроенный сервер эти скрипты умеют? А то я давно отказался от приложения амнезии именно по этой причине.
Уже было такое, когда мертворржденный windows millennium рекламировали
Ну так все, кроме разработчиков, будут рады. Особенно менеджеры. Чем не повод вернуть всех в офисы. /sarcasm
Но если по сабжу, то тут всё, как говорится, it depends. Впрочем, если компания настолько экономит что не может позволить себе минимальную инфраструктуру, то вряд ли она будет заморачиваться в целом. Возьмет первое что более-менее работает.
Даже в локальной сети? Это как?