Коли слід створити галузі розвитку?

Ми переміщуємо команду нашого проекту від використання однієї основної / магістральної гілки, до декількох гілок розвитку / роботи, які слід регулярно об'єднувати в основні. Ми базуємо свій новий процес на цій статті та керівництві з розгалуження TFS (ми використовуємо TFS та Visual Studio 2010).

Зараз над проектом в будь-який час працює від 1 до 5 осіб. Основні повинні бути стабільними в усі часи, тому що ми хочемо, щоб опція була випущена, коли нам потрібно. У нас немає фіксованих спринтів - принаймні, поки що - і наразі випускаються кожні 1-2 тижні.

Саме в цей момент кожна людина виправляє помилки в додатку. Через пару тижнів ми розпочнемо розробку нового великого компонента для програми.

Одним із важливих моментів, який ми знаходимо, є створення галузей розвитку . Ми будемо реалізовувати кілька історій користувача паралельно залежно від набору навичок розробника. Ми думали над створенням філії для кожного розробника, але це не має сенсу, оскільки завжди буде потреба у співпраці в роботі. Ми не можемо обійтись із однією галуззю розвитку, тому що ми захочемо об'єднатись з Main, поки буде завершена інша робота.

Хтось має якісь вказівки з цього приводу?

Я не захоплююсь довільними гілками, тобто виправленнями Фреда або виправленнями Гаррі. Мені набагато комфортніше одна (незалежна) функція однієї гілки, яка дозволяє декільком розробникам працювати над однією функцією; але для об'єднання функції можна об'єднати лише тоді, коли вона завершена.

Отже, зараз вам потрібна лише гілка "виправлення", але як тільки ви розпочнете розробку, ви повинні створити гілку для кожної важливої ​​функції. Таким чином, коли вони будуть виконані, їх можна об'єднати в & випустити, не залежачи від інших функцій помилок.

Не впевнений, наскільки хороший TFS в злитті, але я впевнений, що ви дізнаєтесь через кілька місяців :)

Ми не можемо обійтись із однією галуззю розвитку, тому що ми захочемо об'єднатись з Main, поки буде завершена інша робота.

Здається, ви вже знаєте, що необхідно створити кілька галузей розвитку. На думку спадають два ймовірні сценарії:

1. Кожен з п'яти розробників працює на незалежні частини проекту (помилка фіксації) - Переконайтеся в тому , що окрема гілка буде створена для кожного розробника. Це покладає тяжкість і відповідальність на кожного розробника, щоб переконатися, що їх набір змін не суперечить роботі будь-кого іншого. Велика ймовірність, що хтось із п’яти розробників допустить помилку. Якщо / коли це так, для всіх інших немає сенсу затримуватися.
2. Розробка декількох функцій - Незалежно від кількості розробників, які працюють над певною функцією / помилкою, їх слід розділити. Прикладом цього корисного є те, що всі кодові комітети є частиною функцій, які розробляються - жодного другого здогадування не задіяно.

Приховані робочі відділення з DVCS

Ми використовуємо Mercurial, тому на скрипті для розробників є мається на увазі робоча гілка. Зв'язок завжди робиться місцевому робочому простору. Коли робота, яка звільняється, завершена, її підсувають до основного сервера репо, де він автоматично вбудовується і тестується.

Ми майже ніколи не створюємо явних гілок, але знову ж таки, наші спринти ніколи не перевищують 1 тиждень і картки займають не більше 1-2 днів.

Крім того, ви можете пом'якшити біль злиття, ввівши роботу з інших частин коду чи інших проектів, щоб людям не потрібно було постійно робити важкі злиття.

Я використовував як одну гілку на історію, так і одну гілку на випуск (усі розробники зареєстрували свої історії до розробника, і якщо будь-яка з них зламає гілку Dev, вона зламана для всіх). Я б дуже рекомендував по одній гілці в історії, якщо вам не подобаються конфлікти. Гілка розробників завжди залишатиметься стабільною для всіх розробників, і не буде часу на очікування розробника, який працює над кодом, який інший розробник вже зламав. Коли ваша історія закінчена, весь ваш код знаходиться у вашій філії. Ви з’єднаєте його з розробником, але не будете реєструватися та перевіряти, якщо у вас виникнуть конфлікти, ви вирішите це питання і попросите людину, з якою ви конфліктуєте, уникати його видалення. Тоді зливайся з dev. Це допомагає всім розробникам працювати безперебійно. Це також залежить від розміру компанії. Наша компанія має 200 розробників, які працюють одночасно на одній базі коду, але окрема гілка для їх оповідань. Після злиття коду з гілкою розробки, гілка історії негайно видаляється. Я сподіваюся, що це допомагає. Дякую

Якщо це засновано на git, то ви просто створите гілку для кожного виправлення помилок, виправите помилку в найкоротші терміни, з’єднаєте гілку виправлення помилок із гілкою розвитку, а потім натисніть на зміну до гілки розвитку. Перегляд запитів на витягування та об’єднання має бути найвищим пріоритетом, адже чим швидше ви це зробите, тим більше шансів, що об'єднання не спричинить проблем. Після об'єднання ці гілки можна видалити.