docs: опиши работу с сабмодулями и добавь сборку Doxygen
This commit is contained in:
185
NEW_PROJECT.md
185
NEW_PROJECT.md
@@ -120,3 +120,188 @@ USB gs_usb и конкретной разводки адаптера; перен
|
||||
|
||||
Так новый проект не является копией старого: он использует общие ядра одной
|
||||
версии, а аппаратные отличия видны в одном небольшом каталоге `port/`.
|
||||
|
||||
## Слияние и обновление `templates` как Git submodule
|
||||
|
||||
### Что именно хранит основной проект
|
||||
|
||||
Основной проект не хранит содержимое `lib/templates` в своей истории. Вместо
|
||||
этого он хранит **gitlink** — ссылку на один конкретный commit репозитория
|
||||
`templates`. Поэтому при работе есть два независимых уровня истории:
|
||||
|
||||
1. изменения библиотек сливаются и публикуются в репозитории `templates`;
|
||||
2. основной проект отдельным коммитом переводит gitlink на проверенную ревизию
|
||||
`templates`.
|
||||
|
||||
Обычный `git merge` в основном проекте не переносит исходники между ветками
|
||||
`templates` и не создаёт merge-коммит внутри сабмодуля. Он может только выбрать
|
||||
одну из уже существующих ссылок на commit. Если ссылки разошлись, сначала нужно
|
||||
получить общий commit в самом `templates`, а затем зафиксировать его в основном
|
||||
проекте.
|
||||
|
||||
Текущую зафиксированную ревизию удобно смотреть из корня основного проекта:
|
||||
|
||||
```bash
|
||||
git submodule status lib/templates
|
||||
git diff --submodule=log
|
||||
```
|
||||
|
||||
Символ `-` перед SHA в `git submodule status` означает, что сабмодуль ещё не
|
||||
инициализирован; `+` — что рабочая копия сабмодуля находится не на том commit,
|
||||
который записан в основном проекте; `U` — конфликт gitlink.
|
||||
|
||||
### Клонирование проекта и переключение его веток
|
||||
|
||||
Новый клон лучше сразу создавать вместе с сабмодулями:
|
||||
|
||||
```bash
|
||||
git clone --recurse-submodules <url-основного-проекта>
|
||||
cd <основной-проект>
|
||||
```
|
||||
|
||||
Если проект уже клонирован:
|
||||
|
||||
```bash
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
После `git switch`, `git checkout`, `git pull` или завершения слияния основной
|
||||
проект может начать ссылаться на другую ревизию `templates`. Рабочее дерево
|
||||
сабмодуля следует явно привести к записанному состоянию:
|
||||
|
||||
```bash
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
Это нормальный и воспроизводимый режим: внутри `lib/templates` обычно будет
|
||||
detached HEAD, потому что проект фиксирует commit, а не ветку. Не следует делать
|
||||
там `git pull`, пока не выбрана рабочая ветка и не понятно, какую ревизию должен
|
||||
получить основной проект.
|
||||
|
||||
### Обычное обновление проекта на новую версию `templates`
|
||||
|
||||
Сначала изменение должно быть проверено, закоммичено, отправлено и слито в
|
||||
целевую ветку самого репозитория `templates`. После этого из корня основного
|
||||
проекта выполняется:
|
||||
|
||||
```bash
|
||||
git -C lib/templates fetch origin
|
||||
git -C lib/templates switch --detach origin/master
|
||||
git add lib/templates
|
||||
git diff --cached --submodule=log
|
||||
git commit -m "build(templates): обновить общие библиотеки"
|
||||
```
|
||||
|
||||
Перед коммитом нужно собрать основной проект и прогнать его тесты: успешные
|
||||
тесты в `templates` подтверждают работу библиотеки, но не проверяют конкретный
|
||||
порт, настройки платы и интеграцию приложения.
|
||||
|
||||
Коммит основного проекта содержит только переход со старого SHA сабмодуля на
|
||||
новый. Случайные незакоммиченные файлы внутри `lib/templates` в него не входят.
|
||||
Проверить оба уровня перед фиксацией можно так:
|
||||
|
||||
```bash
|
||||
git status
|
||||
git -C lib/templates status
|
||||
git diff --submodule=log
|
||||
```
|
||||
|
||||
Не нужно обновлять сабмодуль на последний `master` автоматически при каждой
|
||||
сборке. Зафиксированный SHA нужен именно для того, чтобы одна и та же версия
|
||||
проекта всегда собиралась с одной и той же версией библиотек.
|
||||
|
||||
### Если библиотеку правят из рабочего дерева основного проекта
|
||||
|
||||
Нельзя коммитить изменение, оставаясь на detached HEAD: такой commit легко
|
||||
потерять при следующем `git submodule update`. Сначала внутри сабмодуля создаётся
|
||||
обычная ветка:
|
||||
|
||||
```bash
|
||||
git -C lib/templates fetch origin
|
||||
git -C lib/templates switch -c feat/<имя> origin/master
|
||||
```
|
||||
|
||||
Затем изменения коммитятся и отправляются именно в репозиторий `templates`:
|
||||
|
||||
```bash
|
||||
git -C lib/templates add <файлы>
|
||||
git -C lib/templates commit -m "feat(<библиотека>): <описание>"
|
||||
git -C lib/templates push -u origin feat/<имя>
|
||||
```
|
||||
|
||||
После проверки ветка сливается в `master` репозитория `templates`. Только после
|
||||
публикации итогового commit основной проект обновляет свой gitlink по процедуре
|
||||
из предыдущего раздела. Не следует отправлять в общий основной проект ссылку на
|
||||
commit сабмодуля, которого ещё нет на сервере: остальные разработчики и CI не
|
||||
смогут его получить.
|
||||
|
||||
### Что происходит при слиянии веток основного проекта
|
||||
|
||||
Возможны три ситуации:
|
||||
|
||||
1. Gitlink изменён только в одной ветке. Git обычно принимает эту ревизию
|
||||
автоматически. После merge нужно выполнить `git submodule update` и тесты.
|
||||
2. Обе ветки указывают на разные commits, но один commit `templates` является
|
||||
предком другого. Следует выбрать более новый проверенный commit, выполнить
|
||||
`git add lib/templates` и продолжить merge.
|
||||
3. Обе ветки указывают на расходящиеся commits `templates`. Это настоящий
|
||||
конфликт истории сабмодуля: выбирать один SHA наугад нельзя, потому что так
|
||||
потеряются изменения второй ветки.
|
||||
|
||||
При конфликте сначала смотрят, какие ссылки пришли с обеих сторон:
|
||||
|
||||
```bash
|
||||
git ls-files -u lib/templates
|
||||
git -C lib/templates fetch origin
|
||||
git -C lib/templates log --oneline --graph --decorate --all
|
||||
```
|
||||
|
||||
Затем в отдельной ветке **репозитория `templates`** объединяют оба commit,
|
||||
устраняют конфликты исходников, запускают тесты и публикуют результат:
|
||||
|
||||
```bash
|
||||
git -C lib/templates switch -c merge/<имя> <sha-одной-стороны>
|
||||
git -C lib/templates merge <sha-другой-стороны>
|
||||
# исправить конфликты и запустить тесты templates
|
||||
git -C lib/templates add <исправленные-файлы>
|
||||
git -C lib/templates commit
|
||||
git -C lib/templates push -u origin merge/<имя>
|
||||
```
|
||||
|
||||
Если общий merge-коммит уже существует в `origin/master`, создавать ещё один не
|
||||
нужно: достаточно выбрать существующий SHA. После получения итогового commit
|
||||
конфликт завершается на уровне основного проекта:
|
||||
|
||||
```bash
|
||||
git -C lib/templates switch --detach <итоговый-sha>
|
||||
git add lib/templates
|
||||
git diff --cached --submodule=log
|
||||
git merge --continue
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
`git add lib/templates` здесь отмечает разрешённым именно gitlink. Не нужно
|
||||
удалять каталог, копировать библиотеку поверх него или разрешать конфликт как
|
||||
обычный текстовый файл.
|
||||
|
||||
### Что должно попасть в merge request основного проекта
|
||||
|
||||
Перед отправкой результата следует проверить:
|
||||
|
||||
1. итоговый commit `templates` доступен в удалённом репозитории;
|
||||
2. `git -C lib/templates status` не показывает локальных изменений;
|
||||
3. `git submodule status` не начинается с `+`, `-` или `U`;
|
||||
4. `git diff --submodule=log <целевая-ветка>...HEAD` показывает ожидаемый набор
|
||||
commits библиотек;
|
||||
5. тесты `templates`, сборка основного проекта и проверки на целевой плате
|
||||
прошли;
|
||||
6. в основном проекте закоммичены необходимые изменения адаптеров, конфигурации
|
||||
и сам новый gitlink.
|
||||
|
||||
После получения ветки другой разработчик восстанавливает ровно выбранное
|
||||
состояние одной командой:
|
||||
|
||||
```bash
|
||||
git pull
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user