Разработка и контроль версий

Это зависит от того, любишь ли ты старые истории и интересен ли тебе ответ на сакраментальный вопрос: «что хотел сказать автор?» вот тут и вон там.

Если багтрекера вообще нет, т.к. вся команда сидит на одном этаже и все могут обратиться лично, то поступаю по второму способу. Просто нужно коммиты делать информативными.

все зависит от архитектора и тим лида. но когда в проекте более двух человек желательно как минимум в разные ветки этапы разносить, пусть даже и без issue

issue нужен, ссылки на него в комментах коммитов нужны, бранч по желанию. Если функционал такой, что на первое время может полностью разломать дерево исходников, то бранч обязателен.

На каждое изменение функционала заводить в багтрекере новый issue

Тогда уж не issue, а requirement

Или же, тупо коммитить каждое изменение в основной бранч без излишней бюрократии в виде issue в багтрекере?

Ты спутал и смешал 2 независимых аспекта:
* документирование изменений vs «без бюрократии»
* разработка во множестве веток vs разработка в «основной» ветке

так и делаем. бранчи обязательно.

Немного лишняя работа, зато легче разобраться потом.

Зависит размера команды и продолжительности проекта.

С маленькой командой (пара человек) оверхед на документирование может быть просто адским, неоправданным. Если же у вас на проекте 5 разарбов, 5 тестеров, архитектор и аналитик, то без документирования всё утонет в неразберихе и хаосе.

Подход с отдельными ветками рискован болезненными мерджами в конце разработки, если модифицировались одни и те же фрагменты кода. Но за то он хоть как-то масштабируется на гигантские команды..

Первый вариант.

Подход с отдельными ветками рискован болезненными мерджами в конце разработки

Мерж неизбежен даже без бранча.

Мерж неизбежен даже без бранча.

1. Если в разных бранчах код был модифицирован в разные дни, то без бранчей мердж может и не потребоваться (делай svn up каждое утро, сабмить каждый день по мере готовности очередного кусочка кода, и ты даже не заметишь, что тут топтался кто-то кроме тебя).
2. Маленькие патчи мерджить гораздо менее болезненно, чем большие. Просто потому, что в голове нужно меньше информации держать единовременно.
3. Мердж производится значительно раньше, поэтому все авторы очень хорошо помнят, что именно и зачем именно они меняли. Это также облегчает мердженье.

мердж может и не потребоваться (делай svn up каждое утро

svn up - это мерж.

Маленькие патчи мерджить гораздо менее болезненно
Мердж производится значительно раньше

Используй rebase, который не замусоривает историю.

мне очень понравилось, как написанов пдфке «The Importance of Branching Models in SCM» - загугли - она будет на первой странице

или вот она же http://docis.info/strip/docis/lib/goti/rclis/dbl/ieecom/(2002)35%3A9%3C31%3AT...

И тем не менее, в случае разработки в общей «основной» ветке, риск, связанный с обширными и сложными мерджами в конце разработки, исчезает.

в случае разработки в общей «основной» ветке, риск, связанный с обширными и сложными мерджами в конце разработки, исчезает.

Плата за это - мусорная история и потенциальная дестабилизация общей кодовой базы. rebase решает обе проблемы.

rebase решает обе проблемы.

Давай разберем на примере. Есть некая кодовая база, старшему разработчику Джамшуту поручено разработать фичу «Д», ведущему разработчику Равшану поручено разработать фичу «Р».

Без отдельных бранчей:
1. Вторник, Джамшут коммитит ревизию 2 файла file.cpp
3. Среда, Равшан делает svn up, и получает ревизию 2 файла file.cpp
3. Четверг, Равшан коммитит ревизию 3 файла file.cpp
4. Неделю спустя, Равшан завершил разработку фичи «Р»
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д»

В итоге, Равшан и Джамшут друг другу совсем не мешали, не смотря на то, что правили один и тот же file.cpp. Равшан изначально рассматривал этот файл с Джамшутовскими правками.

С отдельными бранчами:
1. Вторник, Джамшут меняет file.cpp у себя
3. Четверг, Равшан меняет file.cpp у себя
4. Неделю спустя, Равшан завершил разработку фичи «Р», и вливает все 5000 строк изменений в 20 файлах в trunk
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д», хочет влить 7000 строк изменений в 30 файлах в trunk, но обаруживает конфликт в file.cpp

В итоге, Равшан и Джамшут еще три дня судорожно курят file.cpp, пытаясь вспомнить что и зачем они там направили, и как теперь эти правки скрестить, чтобы ничего не сломать.

потенциальная дестабилизация общей кодовой базы

Для этого есть continuous integration

Зависит от размера изменения.

У нас есть master, есть dev ветки и по ветке на каждый баг/группу багов. После закрытия бага/группы багов ветка мерджится с dev и удаляется. Если в dev всё хорошо и здорово, правятся мелки огрехи и мерджится в master, потом выкатывается. Новые фичи заводятся в виде отдельной ветки, которая ребейзится от мастера в процессе реализации фичи, так что к концу всё безболезненно сливается вместе и ветка удаляется.

На каждое изменение функционала заводить в багтрекере новый issue

багтрекер для багов же, зачем туда лишние вещи писать?

или баг - это отсутствие разрабатываемой фичи?

В первую очередь не полениться создать/обновить документацию. Также разумеется создавать новую ветку, а потом мержить. Если и создавать issue на багтрекере, то уже не issue в таком случае, а feature или requirement

перед тем как мержить в основную ветку, то нужно протестировать набором тестов, что не ясного? риск сломать есть всегда, для предотвращение существует регрессионное тестирование и юнит-тестирование

смотри, если в документации сказано, что у программного продукта должна быть возможность генерировать qr-коды, а реализации нет, то заводится issue, если же заказчик просит добавить распознавание штрих-кодов, а это не предусмотрено спекой, то открывается feature request или requirement

если в документации сказано, что у программного продукта должна быть возможность генерировать qr-коды, а реализации нет, то заводится issue

В этом случае самого начала должен был быть заведен requirement. И пока реализации нет, этот requirement числится невыполненным — так что его даже не пытаются тестировать.

В принципе так и так правильно, зависит от политики компании.

перед тем как мержить в основную ветку, то нужно протестировать набором тестов, что не ясного?

Неясно, с чего ты решил поучить меня основам.

Равшан и Джамшут друг другу совсем не мешали, не смотря на то, что правили один и тот же file.cpp

Оkay.

но обаруживает конфликт в file.cpp

А совсем недавно они друг другу не мешали.

В итоге, Равшан и Джамшут еще три дня судорожно курят file.cpp, пытаясь вспомнить что и зачем они там направили

Прошло всего 10 дней, и они уже 3 дня не могут вспомнить, несмотря на логи и диффы? То ли твоя фантазия вышла из-под контроля, то ли они дебилы.

потенциальная дестабилизация общей кодовой базы

Для этого есть continuous integration

И? Во время разработки новой фичи обязательно будут сломанные тесты, а проверка «кодовая база собирается» обычно бесполезна.

Это я не тебе отвечал, извини. Не думал, что вызывающе выглядит)

Ну и как поступаете вы?

простые фичи - в основную ветку без бюрократии.

сложные (долгие в реализации) фичи - в отдельную ветку, тоже без бюрократии.

А совсем недавно они друг другу не мешали.

Потому что тогда они работали в общей ветке; выше я подробно описал, как так получилось.

Прошло всего 10 дней, и они уже 3 дня не могут вспомнить, несмотря на логи и диффы?

10 дней активного кодинга. Теперь несколько дней уйдёт на мердж. Это не среднестатистический случай, но иногда риски срабатывают, и приходится с таким случаем иметь дело на практике.

И? Во время разработки новой фичи обязательно будут сломанные тесты, а проверка «кодовая база собирается» обычно бесполезна.

Не коммить, пока не починишь тесты.