Таким образом, каждое приложение похоже на отдельную ветвь фреймворка, но оно никогда не будет полностью объединено (потому что это отдельное приложение), и необходимо выполнить некоторые коммиты для фреймворка (транка).В некоторых онлайн-статьях такие коммиты (без слияния целой ветви с транком) приводятся в качестве отрицательных примеров, поэтому мы запутались.
Эта часть меня немного пугает.Если у вас будет фреймворк, вам нужно позаботиться об этом, как о любом другом фрагменте кода, и вы не хотите, чтобы несколько версий работали по любой причине, за исключением обслуживания существующих выпусков или работы над будущими выпусками.Таким образом, каждый из ваших «прикладных» проектов может иметь свою ветвь, в которой они изменяют платформу так, как требуется для приложения, но я рекомендую часто обновлять ствол платформы, чтобы он развивался таким образом, который наилучшим образом отвечает потребностям всех ваших приложений.В общем, при переходе к следующему коду необходимо синхронизироваться с мастером и как можно быстрее поместить код обратно в мастер, чтобы избежать большого количества слияний при обработке работы, а также дать другим преимущество в работе.
Вы должны поместить свою платформу в отдельную область (или репозиторий, если вы используете DVCS, например, git или hg), чтобы она отличалась и могла иметь свой собственный цикл выпуска, если это необходимо.
DVCS - это всеярость в эти дни, git и hg являются самыми популярными, так что вы должны изучить их.У них есть разные способы обработки ветвления.Их сила заключается в том, что не существует централизованного репозитория, поэтому он более гибок и надежен для больших команд.