Гениально! Вы всерьёз считаете, что вот этот вот patch на 90 мегабайт — можно разбить на десяток «небольших фич, которые будут отлично просматриваться в истории»? Там изменено всего-то 5% проекта. Какие-то жалкие 59806 файлов изменены. Подумаешь. Мелочь какая. Даёшь change'и на 100000 строк каждый!
Что, вот правда не видим разницы между тэгом версии и коммитом фичи/фикса? Если нет, то гуглим linux 4.12 changelog и внимательно считаем количество фиксов и фич в этом релизе. Вот именно столько должно было быть коммитов, а не один, десяток или 42. One feature — one commit
Как показывает практике «полное покрытие тестами» ни разу не гарантирует, что у вас всё будет работать правильно — при условии, что у вас задача нетривиальна и в ней много взаимозавимимостей.
А типа merge вместо rebase гарантирует?
Опять-таки? С чего вы взяли? Если у вас был проект, помогающий вам «пасти котов» и там, через строчку, были классы «Cat», «CatBehavior» и тому подобные — а вы решили поддержать ещё и собак, то у вас легко может измениться половина строк в проекте из-за появления классов (интерфейсов в Java) «Animal», «AnimalBehavior» и тому подобное.
Да, и эта функциональность должна быть разбита на несколько фич. Как минимум вынесение общей логики в абстрактные классы — отдельной фичей.
И если бы Alex Deucher (добавивший в вышеупомянутую «маленькую фичу на миллион строк добрые 300'000 оных строк) не разделял механические коммиты и „реальные“, то разобраться в этой каше не смог бы никто и никогда…
Неважно, сколько строк затронула фича. Важно какой процент от codebase это составило. Если 10000 строк — это 1% от всего проекта, значит это небольшая фича, которая отлично просматривается в истории. И да, при таком объеме кода эта фича должна быть полностью покрыта тестами, которые делают крайне маловероятной ситуацию "все поломалось". А если 10000 строк — это 50%+ вашего проекта, то это значит, что кто-то не умеет дробить фичи на части. Это уже не фича, а переписывание половины проекта и такого коммита, конечно же быть не должно. Но вторая ситуация встречается только у не слишком умных или дисциплинированных разработчиков, которые привыкли всю разработку вести в одной ветке, временами мерджа ее в мастер и продолжая дальше. Излишне говорить, что это пагубная практика и от нее нужно избавляться весьма решительным образом.
Но есть и альтернативное мнение (которого я придерживаюсь), которое состоит в том, что коммиты в feature-ветке — это поток мыслей разработчика пока он работал над веткой. На эти мысли многое может оказывать влияние: погода, настроение, успехи/неуспехи в личной жизни, разработчик может ставить эксперименты и попросту хулиганить. И я вполне допускаю, что он имеет на все это право. Но в конечном итоге мне нужна готовая фича, а не его поток мыслей. Мне нужна квинтэссенция таска, выраженная в коде. И поэтому это должен быть один красивый и рабочий (желательно) коммит с красивым описанием и ссылкой на баг-трекер. А поток мыслей пусть останется с разработчиком как часть его личности, отраженная в его личностных воспоминаниях. В гите это все не нужно. ИМХО
Попробуйте пару раз вмерджить master ветку в вашу feature-ветку с фиксом конфликтов, а потом все это счастье вмерджить обратно в master. И покажите вашу клевую визуализацию того, что получилось. Я дичайше хочу заценить
Мы НЕ теряем историю. Мы делаем ее лучше. На собственной шкуре установил, что без rebase история абсолютно нечитабельна и переполнена идиотскими сообщениями типа fixed, updated и пр. Но как только команда начинает хотя бы делать squash — тут же история становится полезной. One feature — one commit
В том-то и дело, что я тоже cherry-pick имел в виду, но перед мерджом во избежание конфликтов нужно будет этот коммит в feature-branch скипнуть, а это уже rebase
Кому нужно?
Круто! Это библиотека была бы очень крутой году эдак в 2001-м. Жаль, что на дворе уже 2018-й
Согласен. Жена и дети — главные враги open-source. Кроме шуток :)
ИМХО нативный десктоп будет умирать. Electron всех сожрет
Когда уже Docker добавят нормально в Windows? Hyper-V — ваще не вариант
Что, вот правда не видим разницы между тэгом версии и коммитом фичи/фикса? Если нет, то гуглим linux 4.12 changelog и внимательно считаем количество фиксов и фич в этом релизе. Вот именно столько должно было быть коммитов, а не один, десяток или 42. One feature — one commit
А типа merge вместо rebase гарантирует?
Да, и эта функциональность должна быть разбита на несколько фич. Как минимум вынесение общей логики в абстрактные классы — отдельной фичей.
Смотрим выше, чем отличается версия от фичи.
Неважно, сколько строк затронула фича. Важно какой процент от codebase это составило. Если 10000 строк — это 1% от всего проекта, значит это небольшая фича, которая отлично просматривается в истории. И да, при таком объеме кода эта фича должна быть полностью покрыта тестами, которые делают крайне маловероятной ситуацию "все поломалось". А если 10000 строк — это 50%+ вашего проекта, то это значит, что кто-то не умеет дробить фичи на части. Это уже не фича, а переписывание половины проекта и такого коммита, конечно же быть не должно. Но вторая ситуация встречается только у не слишком умных или дисциплинированных разработчиков, которые привыкли всю разработку вести в одной ветке, временами мерджа ее в мастер и продолжая дальше. Излишне говорить, что это пагубная практика и от нее нужно избавляться весьма решительным образом.
Но есть и альтернативное мнение (которого я придерживаюсь), которое состоит в том, что коммиты в feature-ветке — это поток мыслей разработчика пока он работал над веткой. На эти мысли многое может оказывать влияние: погода, настроение, успехи/неуспехи в личной жизни, разработчик может ставить эксперименты и попросту хулиганить. И я вполне допускаю, что он имеет на все это право. Но в конечном итоге мне нужна готовая фича, а не его поток мыслей. Мне нужна квинтэссенция таска, выраженная в коде. И поэтому это должен быть один красивый и рабочий (желательно) коммит с красивым описанием и ссылкой на баг-трекер. А поток мыслей пусть останется с разработчиком как часть его личности, отраженная в его личностных воспоминаниях. В гите это все не нужно. ИМХО
У меня??? Вот это номер! Да я же тут за это и топлю! А вот автор статьи жестко ставит вопрос: rebase применять нельзя
Если вы смерджите прод к себе, то у вас въедет все, что там есть. А вам сейчас нужен только один единственный фикс.
Одна и та же строка изменена в двух разных коммитах. Не забывайте, что при cherry-pick создается новый коммит, а не копируется начальный.
Моя идея не в том, что будет более одного коммита с багом, а в том, что будет более одного нерабочего коммита. Постарайтесь понять разницу
А по каким коммитам и в какой последовательности пойдет git bisect в вашем примере?
Тащемта в задачке о том и речь была.
Попробуйте пару раз вмерджить master ветку в вашу feature-ветку с фиксом конфликтов, а потом все это счастье вмерджить обратно в master. И покажите вашу клевую визуализацию того, что получилось. Я дичайше хочу заценить
В том-то и суть, что нельзя мерджить master в feature. Только rebase. А вот feature в master — merge
В статье описаны надуманные проблемы людей, которые не умеют и не хотят учиться использовать rebase
Мы НЕ теряем историю. Мы делаем ее лучше. На собственной шкуре установил, что без rebase история абсолютно нечитабельна и переполнена идиотскими сообщениями типа fixed, updated и пр. Но как только команда начинает хотя бы делать squash — тут же история становится полезной. One feature — one commit
В том-то и дело, что я тоже cherry-pick имел в виду, но перед мерджом во избежание конфликтов нужно будет этот коммит в feature-branch скипнуть, а это уже rebase
У вас там что, все фикс ветки с начала времен хранятся? вы не удаляете ветки после ПР и мерджа?