Работа с системой управления версиями при Agile разработке презентация

2008

имеет очень глубокие корни, но очень простые принципы: сохраняйся и обновляйся чаще.
В большинстве случаев оно используется как:
Хранилище исходных текстов и ресурсов программ
Средство обмена исходными текстами (синхронизации работы)

могу…»)
Конфликты при «коммите»

проблем (возможно чаще), чем больших (возможно реже)
Всегда рабочее состояние
Даже после большой неудачной работы в репозитарии есть рабочая копия чего-то
Простота
Все члены команды используют одну и ту же схему изо дня в день, как следствие все процедуры ясны и понятны

публикацию в trunk.


Ожидание пока параллельная задача будет закончена или пока другая группа применит Ваши изменения, не может рассматриваться как решение. Это будет подобно снежному кому – поэтому необходимо выработать некоторые правила.

рамках одно группы. Пытаться фокусироваться на одной задаче.
Если кто-то собирается начать параллельную работу – подождать пока предыдущая задача будет опубликована. Либо создать новую ветку для неё (если нравится жонглировать ветками).
Если кто-то начинает параллельную работу и она требует изменения существующего кода – начинайте с создания нового кода (новые классы, новые методы, новые тесты), но без модификаций существующего кода. Как только первая работа будет опубликована – можно начинать изменять код.

ветви. Включая весь предыдущий функционал!
Синхронизируйте вашу ветвь с основной периодически ( = как можно чаще)

основной ежедневно (как минимум).
Сразу разрешайте проблемы на вашей рабочей ветви.
Объединяйте Вашу рабочую ветвь с основной на периодической основе. Например по окончании задачи (разумеется нерабочий или «ломающий» код выкладывать нельзя). Не ждите окончания спринта.
Тот кто первый объединил – выиграл. В случае возникновения конфликтов при слиянии – он их исправлять уже не будет. Будет тот, кто производил слияние последним.

электронном виде, на русском)