Вы с GitHub/BitBucket и их Pull/Merge Request'ами работали? Если да, то было бы интересно услышать сравнение оных с работой в RB. Я к тому спрашиваю, что ревью отдельных коммитов все же кажется мне несколько неоптимальным.
Поясню свою позицию. Pre-Tesred Commi суть костыль на случай, когда коммитить по какой-то причине нельзя, а результат интеграции узнать хочется. «Какая-то причина» в случае с CVCS — сама система контроля версий,
Я в Jenkins'е не волоку, но тот же Bamboo, например, умеет использовать Build Plan «родительской» ветки для веток «дочерних». Это позволяет каждому разработчику разносить свою ветку (или форк) вдребезги и пополам, запускать билды для _конкретных_ ревизий (а не для непонятно чего в виде патча) и не тревожить mainline.
С форками в CVCS мы все знаем, как обстоит. С бранчами несколько лучше, но тоже не сахар. Посему таковой функционал — лучшее, что можно предложить в случае с CVCS.
.jpg"/>разбросаны по тексту.news.ycombinator.com/item?id=6081508
news.ycombinator.com/item?id=6080620
news.ycombinator.com/item?id=6078832
news.ycombinator.com/item?id=6071233
Вы с GitHub/BitBucket и их Pull/Merge Request'ами работали? Если да, то было бы интересно услышать сравнение оных с работой в RB. Я к тому спрашиваю, что ревью отдельных коммитов все же кажется мне несколько неоптимальным.
Поясню свою позицию. Pre-Tesred Commi суть костыль на случай, когда коммитить по какой-то причине нельзя, а результат интеграции узнать хочется. «Какая-то причина» в случае с CVCS — сама система контроля версий,
Я в Jenkins'е не волоку, но тот же Bamboo, например, умеет использовать Build Plan «родительской» ветки для веток «дочерних». Это позволяет каждому разработчику разносить свою ветку (или форк) вдребезги и пополам, запускать билды для _конкретных_ ревизий (а не для непонятно чего в виде патча) и не тревожить mainline.
С форками в CVCS мы все знаем, как обстоит. С бранчами несколько лучше, но тоже не сахар. Посему таковой функционал — лучшее, что можно предложить в случае с CVCS.