---
url: /template-sync-strategy/concepts/model.md
description: Роли веток и remote в стратегии обновления проекта от шаблона.
---

# Модель веток

Целевая схема:

```text
templates/master -> template -> sync/* -> master
```

Это логическая модель ответственности. Она не требует физически разделять файлы шаблона и приложения по папкам.

## templates/master

`templates/master` — это `master` из репозитория шаблона.

В репозитории приложения он доступен через remote `templates`:

```bash
git remote add templates <template-repo-url>
git fetch templates
```

Этот remote считается источником обновлений шаблона.

## template

`template` — чистый слепок шаблона внутри репозитория приложения.

Его задача — показать, какая версия шаблонной базы сейчас доступна приложению.

В `template` нельзя коммитить руками изменения приложения. Эта ветка обновляется только из `templates/master`.

## master

`master` — основная ветка приложения.

Она содержит:

* базу шаблона;
* продуктовый код;
* локальные настройки приложения;
* историю применения обновлений шаблона.

`master` не используется как место ручного решения конфликтов при обновлении шаблона.

## sync/\*

`sync/*` — временная ветка для обновления приложения от шаблона.

Она создаётся от актуального `origin/master`, после чего в неё вливается `origin/template`.

Пример:

```bash
git fetch origin
git switch -c sync/update-template-v2 origin/master
git merge origin/template
```

Если появляются конфликты, они решаются именно в этой ветке.

## Почему нужен отдельный sync-слой

Нельзя безопасно использовать `template` как source branch для прямого PR/MR в `master`: если возникнет конфликт, решение может попасть в `template`.

После этого `template` перестанет быть чистым слепком шаблона. Git начнёт видеть в ней не только шаблон, но и локальные решения конкретного приложения.

`sync/*` можно пачкать conflict resolve-коммитами, проверками и правками совместимости. Эта ветка временная и удаляется после merge.