В том-то и дело, что я тоже cherry-pick имел в виду, но перед мерджом во избежание конфликтов нужно будет этот коммит в feature-branch скипнуть, а это уже rebase
Дорогие коллеги, которые выступают категорически против rebase. Внимание, задачка:
Вы отбранчевались от мастера и пилите фичу. В это время в мастер приезжает 4 мерджа: 2 больших фичи, 1 критический фикс, одна большая фича.
Вам нужно интегрировать в свою ветку критический фикс, который приехал с третьим мерждом, но при этом те большие фичи вам не нужны (вы не хотите возиться с сайд-эффектами). Вы категорически не приемлете rebase. Ваши действия
Это троллинг такой? Надеюсь, вы не управляете командой, потому что увольнение за неправильные commit message — это просто жестяк какой-то.
"Иван, вы отлично работали, у вас 10-летний опыт, сделали много прекрасных вещей, но вы делаете неправильные commit message и поэтому мы вас увольняем."
После мёржа в мастер коммиты какими были в ветке, такими и остались. Вы думаете код и мастера в них как-то проникнет? :)
Это шутка? Какая мне разница, что сам по себе коммит в вакууме рабочий? Если он накладывается на мастер, где уже убрана нужная зависимость и значит все, что было, начиная отсюда — не работает. до тех пор, пока не был сделан 11-й коммит, который исправлял положение, внесенное мастером.
Это приводит к проблемам с пониманием что и зачем комитили.
Никаких проблем с пониманием, если в мастер приезжает один единственный коммит с хорошим commit message и ссылкой на таск.
В отличие, кстати, от ситуации, когда в мастер приезжает 11 коммитов с непонятно какими сообщениями (вы не можете быть уверены, что за все время работы над таском разработчик ни разу не закоммитился с ничего не значащим сообщением типа "fixed")
Интересный доводы. Виноваты люди, виноваты инструменты, виноват кто угодно, только не тот, кто не умеет делать rebase. Зачем нужна такая история, которую нельзя посмотреть без стороннего инструмента?
Как это? Merge-commit на то и merge-commit, что он добавляется, а не подменяет все коммиты из локальной ветки. Если же имеется в виду merge --squash, то это по сути равнозначно rebase + merge и я за это и выступаю.
Сильно много "лучше бы". И коммиты подавай вам осмысленные и сообщения о коммитах пиши красивые. Но реальная разработка — она не такая. Часто приходится что-то пробовать, что-то откатывать. К исходу дня в локальной ветке может быть 15-20 коммитов, некоторые из которых прямо противоположны предыдущим. Что тогда?
Нет, у нас будет 10 нормальных коммитов и, возможно один плохой сразу после мёржа.
Лол. Ну как так-то? Зависимость в мастере убрана ДО мерджа фичи. Фикс делался в самом конце. Следовательно все коммиты до мерджа с мастером будут нерабочими.
10 коммитов с ошибкой могут появиться из-за rebase. Они, конечно, никому не нужны и поэтому rebase лучше избегать.
Даже если все 10 коммитов будут сбойными, то rebase для того и создан, чтобы потом сделать fixup и получить на выходе один правильный коммит.
Я редко смотрю историю, чтобы получить понимание, как менялся код коммит за коммитом. Мне интересно увидеть что происходило в отдельном конкретном коммите. Для этого коммиты должны быть простыми и понятными.
Это нужно один единственный раз: во время code review. После этого все коммиты должны быть засквошены и смерджены.
А без rebase после merge ошибка переедет в master — это просто восхитительно. Если же имеется в виду, что мы делаем git merge master, то ситуация никак не меняется, потому что после обратного merge в мастер у нас будет 10 битых коммитов и один merge commit с исправлениями. Вопрос: зачем нужны в истории 10 коммитов с ошибкой? Чтобы увлекательнее было лазить по коду с git bisect?
И таким образом программист прибьёт историю и понять какой код для чего коммитили будет непросто я против такого подхода
В том-то и дело, что я тоже cherry-pick имел в виду, но перед мерджом во избежание конфликтов нужно будет этот коммит в feature-branch скипнуть, а это уже rebase
У вас там что, все фикс ветки с начала времен хранятся? вы не удаляете ветки после ПР и мерджа?
И хранишь все ветки со всеми фиксами с начала времен?
Дорогие коллеги, которые выступают категорически против rebase. Внимание, задачка:
Вы отбранчевались от мастера и пилите фичу. В это время в мастер приезжает 4 мерджа: 2 больших фичи, 1 критический фикс, одна большая фича.
Вам нужно интегрировать в свою ветку критический фикс, который приехал с третьим мерждом, но при этом те большие фичи вам не нужны (вы не хотите возиться с сайд-эффектами). Вы категорически не приемлете rebase. Ваши действия
Ок, тогда так. Сегодня мы судим нашего товарища Ивана. У нас есть доводы за и против:
Иван пишет отличный код
Иван покрывает все тестами
Иван выполняет на 20% больше тасков, чем команда в среднем
Иван пишет плохие commit messages
Вердикт однозначен: УВОЛИТЬ!!!
Надо просто взять себе за правило всегда делать ТОЛЬКО интерактивный rebase. И тогда никаких поломанных коммитов не будет
Это троллинг такой? Надеюсь, вы не управляете командой, потому что увольнение за неправильные commit message — это просто жестяк какой-то.
"Иван, вы отлично работали, у вас 10-летний опыт, сделали много прекрасных вещей, но вы делаете неправильные commit message и поэтому мы вас увольняем."
Ох жесть какая. То есть от нежелания делать rebase я должен заводить столько веток, сколько раз я захотел поэкспериментировать в локальной ветке?
А можно вообще не коммитить, пока таск не сделаешь. Зачем нужен git? Будем коммитить один раз, когда все уже точно готово. :)
Это шутка? Какая мне разница, что сам по себе коммит в вакууме рабочий? Если он накладывается на мастер, где уже убрана нужная зависимость и значит все, что было, начиная отсюда — не работает. до тех пор, пока не был сделан 11-й коммит, который исправлял положение, внесенное мастером.
Никаких проблем с пониманием, если в мастер приезжает один единственный коммит с хорошим commit message и ссылкой на таск.
В отличие, кстати, от ситуации, когда в мастер приезжает 11 коммитов с непонятно какими сообщениями (вы не можете быть уверены, что за все время работы над таском разработчик ни разу не закоммитился с ничего не значащим сообщением типа "fixed")
Интересный доводы. Виноваты люди, виноваты инструменты, виноват кто угодно, только не тот, кто не умеет делать rebase. Зачем нужна такая история, которую нельзя посмотреть без стороннего инструмента?
Как это? Merge-commit на то и merge-commit, что он добавляется, а не подменяет все коммиты из локальной ветки. Если же имеется в виду merge --squash, то это по сути равнозначно rebase + merge и я за это и выступаю.
Как? Если не было конфликтов, как я вообще узнаю, что изменения в мастере поломали мою ветку???
Сильно много "лучше бы". И коммиты подавай вам осмысленные и сообщения о коммитах пиши красивые. Но реальная разработка — она не такая. Часто приходится что-то пробовать, что-то откатывать. К исходу дня в локальной ветке может быть 15-20 коммитов, некоторые из которых прямо противоположны предыдущим. Что тогда?
Лол. Ну как так-то? Зависимость в мастере убрана ДО мерджа фичи. Фикс делался в самом конце. Следовательно все коммиты до мерджа с мастером будут нерабочими.
Даже если все 10 коммитов будут сбойными, то rebase для того и создан, чтобы потом сделать fixup и получить на выходе один правильный коммит.
Это нужно один единственный раз: во время code review. После этого все коммиты должны быть засквошены и смерджены.
Разработчик работает над веткой. Тут он так писал, тут эдак, тут вообще рыбу заворачивал, тут новый фреймворк добавил, тут убрал. Зачем это в мастере?
Ну-ну. Тех, кто плхие коммит сообщения пишет увольнять?
И к тому же, поясните мне, чем лучше 20 одинаковых сообщений типа:
"Fixed #20 Here we have soooo long feature name"
Это не намного информативнее, чем то, что я привел выше
А без rebase после merge ошибка переедет в master — это просто восхитительно. Если же имеется в виду, что мы делаем git merge master, то ситуация никак не меняется, потому что после обратного merge в мастер у нас будет 10 битых коммитов и один merge commit с исправлениями. Вопрос: зачем нужны в истории 10 коммитов с ошибкой? Чтобы увлекательнее было лазить по коду с git bisect?
https://habrahabr.ru/company/mailru/blog/340558/.com[perevod]-pochemu-nuzhno-perestat-ispolz#comment_10486872
С такой историей лучше уж никакой истории. Она только дичайше засоряет git log
Практика показывает, что без squash/fixup 90% вашей истории будет состоять из коммитов типа:
и т.д.
Это не умозрительное предположение, это — факт, который имел место в моей практике.
А с какого перепугу 5 стали поломаны?
Если из 10 коммитов хотя бы один был на сервере, то нужен
Но в локальной ветке. Потом программист сквошит коммиты и вливает одним merge чистенький и исправленный коммит.
One feature — one commit
squash/fixup