---
url: /template-sync-strategy/concepts/rules.md
description: >-
  Набор правил, который удерживает template чистой, а обновления шаблона
  контролируемыми.
---

# Правила процесса

Небольшой набор правил удерживает схему чистой.

## Делаем

* `template` обновляем только из `templates/master`.
* `sync/*` создаём от `origin/master`.
* `origin/template` вливаем в `sync/*`, а не напрямую в `master`.
* Конфликты решаем только в `sync/*`.
* `sync/* -> master` вливаем через PR/MR.
* Для sync-PR/MR отключаем squash.

## Не делаем

* Не правим `template` руками.
* Не коммитим изменения приложения в `template`.
* Не мержим `template -> master` напрямую.
* Не решаем конфликты в `master`.
* Не включаем squash для `sync/* -> master`.

## Почему squash нельзя

Squash может уничтожить нормальную связь истории `master` с историей `template`.

Git использует историю, чтобы понимать, какие изменения шаблона уже были доставлены в приложение. Если результат обновления шаблона превратить в один squash-коммит, связь с исходными коммитами шаблона станет хуже или исчезнет.

Для sync-PR/MR допустимы:

```text
fast-forward merge = хорошо
merge commit       = допустимо
squash merge       = нельзя
```

## Почему template нельзя пачкать

`template` — эталонный слепок оригинального шаблона.

Если в неё попадает локальное решение конфликта или изменение приложения, она перестаёт отвечать на вопрос: “какая версия шаблона сейчас подключена к приложению?”.

После этого ломается главная граница ответственности: шаблон отдельно, приложение отдельно, конфликтная зона отдельно.