Опишите ваш рабочий процесс с Git.

Question

Опишите ваш рабочий процесс с Git.

Тип вопроса: DevOps Вероятность: 10% Категория: IOS Разработчик

Ответ

Я придерживаюсь workflow, основанного на feature-ветках и pull/merge request'ах, что обеспечивает чистую историю и facilitates code review.

Стандартный цикл разработки фичи:

Создание ветки от актуальной main (или develop):

git checkout main
git pull origin main
git checkout -b feature/add-dark-mode

Регулярные коммиты с атомарными и понятными сообщениями:

# Плохо: "fix bugs"
# Хорошо:
git commit -m "Add theme selection UI to settings screen"
git commit -m "Implement system theme detection logic"

Синхронизация с основной веткой для минимизации конфликтов:
```
git fetch origin
git rebase origin/main
```
Разрешение конфликтов (если они возникают при rebase), затем продолжение:
```
git rebase --continue
```

Подготовка истории (опционально, для чистоты) с помощью interactive rebase:

git rebase -i HEAD~5  # Объединить, переименовать, переставить последние 5 коммитов

Отправка ветки и создание Pull/Merge Request (PR/MR):
```
git push origin feature/add-dark-mode
```
- В PR добавляется описание изменений.
- Запускаются CI-проверки.
- Запрашивается ревью от коллег.
Внесение правок по результатам ревью (коммиты добавляются в ту же ветку, история часто переписывается через git commit --amend и git push --force-with-lease).
Слияние через squash или merge commit, в зависимости от политики команды. После мержа ветка удаляется.

Дополнительные практики:

.gitignore: Всегда актуален для iOS (файлы xcuserdata, DerivedData, .DS_Store и т.д.).
Хуки (Hooks): Использую pre-commit хуки для автоматического форматирования кода (например, через SwiftLint).
git cherry-pick: Для переноса критического исправления из одной ветки в другую (например, хотфикс из main в release).

Ответ 18+ 🔞

Да ты посмотри на этого дисциплинированного инженера! Сидит, сука, выписывает себе свод правил, как в армии. Ну ладно, я тоже так живу, а то потом пиздец наступает.

Слушай сюда, мой воркфлоу — это как будто ты монах в монастыре, только вместо молитв — гитовые команды. Основа — фича-ветки и эти вот пулл-реквесты, чтобы не превратить историю в помойку, где никто ни хуя не понимает.

Как я обычно делаю, чтобы не обосраться:

Отпочковаться от главного ствола. Ты ж не с потолка начинаешь, а с актуальной main.
```
git checkout main
git pull origin main
git checkout -b feature/add-dark-mode
```
Ветку называй так, чтобы через месяц было понятно, что ты там ебал.
Коммитить по чуть-чуть, но внятно. Не надо этих «пофиксил баги» — это пиздец какой-то, а не сообщение.
```
# Пиздец как плохо: "fix bugs"
# А вот так — охуенно:
git commit -m "Add theme selection UI to settings screen"
git commit -m "Implement system theme detection logic"
```
Каждый коммит — это одна законченная мысль, а не поток сознания шизофреника.
Не отрываться от реальности. Пока ты тут свою темную тему пишешь, в main уже десять чуваков намержили своё. Надо подтягивать их изменения, иначе потом будет ебанистический конфликт.
```
git fetch origin
git rebase origin/main
```
Ребаз — это наше всё. Он историю держит прямой, как стрела, а не ветвистой, как ёлка.
Если конфликты — не паниковать. Ребаз сказал «конфликт»? Ну, бывает, ебать. Открываешь файлы, смотришь, где наложилось, руками разгребаешь эту кашу, добавляешь и говоришь «продолжаем».
```
git rebase --continue
```
Причесать историю перед показом. Это как перед свиданием — надо выглядеть блёстко. Собрал пять кривых коммитов в один красивый.
```
git rebase -i HEAD~5  # Тут можно склеить, переименовать, выкинуть лишнее
```
Делается, когда ты уже всё сделал и перед тем, как отправить на ревью.
Выставить свою работу на суд. Запушил ветку и создаешь пулл-реквест.
```
git push origin feature/add-dark-mode
```
А в описании пишешь не «сделал», а что именно, зачем и как тестировать. И ждешь, когда коллеги придут и начнут ёрничать.
Исправлять по замечаниям. Пришли правки? Делаешь их в той же ветке. Часто юзаешь git commit --amend, чтобы не плодить коммиты «исправил опечатку», а потом git push --force-with-lease, чтобы аккуратно заменить историю на сервере. Без --force-with-lease лучше не баловаться, а то чужое поудаляешь.
Слияние и забвение. Ревью пройдено, все довольны. Мержим (сквошем или обычным мерж-коммитом — как договорились) и удаляем ветку. Всё, фича стала частью истории.

А ещё из обязательных ритуалов:

.gitignore должен быть святым писанием для айосщика. Чтобы всякие xcuserdata, DerivedData и этот ёбаный .DS_Store случайно не попали в репу. Иначе позор на весь отдел.
Хуки (Hooks) — моя палочка-выручалочка. Pre-commit хук, который автоматом запускает SwiftLint и форматирует код. Чтобы даже в пьяном угаре не закоммитить какую-нибудь дичь.
git cherry-pick — для экстренных случаев. Нашел критичный баг в main, а в release ветке его ещё нет? Берёшь коммит с фиксом и аккуратно, как хирург, переносишь его туда. Чистая работа, без лишнего шума.

Ответ

Ответ 18+ 🔞

Оформление подписки

Международная оплата

Вход на сайт

Введите код

Оформление подписки