?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


Anatoly Borodin
Anatoly Borodin at 2011-06-19 12:24 (UTC) (Link)
> Если довести до такого маразма, это будет мешать работать, когда надо ради исправления опечатки в коменте (и тд. по непрерывному росту важности, опечатка в переменной, неправильный отступ, не очень понятное место кода, ...) работать с Jira/звать ревьювить.

Welcome to the SVN World!

Гуру git и, вроде бы, hg, рекоммендуют под баг/тикет ветку заводить и после ревью мержить.
Gaperton
gaperton at 2011-06-19 12:28 (UTC) (Link)
И bazaar-a тоже. Эта стратегия Feature Branch называется.

Кстати, ничего не мешает то же самое делать с SVN - там бранчевание дешевое. Казалось бы :). Если медленно - берем в качестве клиента к SVN-у Bazaar, и бранчуемся локально.
Lost In Paradox
localstorm at 2011-06-19 12:46 (UTC) (Link)
Это делать можно, но по мне так нужно четко сперва понять, какие проблемы это действительно решит в конкретном проекте. Ибо мерджинг сам по себе -- некая дополнительная операция, которая самостоятельной ценности не имеет, зато может быть проведена некорректно, нанося тем самым вред.
hedgeov
hedgeov at 2011-06-19 18:58 (UTC) (Link)
Если в проекте есть больше одной команды, которая может менять основную ветку с которой релизы делаются, сильно помогает экономить время при конфликте изменений. Даже в ClearCase :-) Альтернатива -- довольно хитрые откаты и согласование изменений через e-mail.
Previous Entry  Next Entry