Работали ли вы с Git?

Question

Работали ли вы с Git?

Тип вопроса: DevOps и инфраструктура Вероятность: 33% Категория: Data Инженер

Ответ

Да, Git — это основной инструмент контроля версий во всех моих проектах. Я использую его ежедневно для командной разработки и управления кодом.

Мой рабочий процесс и опыт:

Ветвление: Работаю по модели Git Flow или упрощенной модели с main, develop и feature-ветками. Создаю ветки для новых задач, исправлений (hotfix) и релизов.
Коммиты: Стараюсь делать атомарные коммиты с четкими сообщениями в формате Conventional Commits (feat:, fix:, docs:).
Слияние: Чаще использую git merge --no-ff для сохранения истории, но для линейной истории применяю git rebase с последующим --force-push в feature-ветку (перед мерж-реквестом).
Разрешение конфликтов: Регулярно сталкиваюсь и решаю конфликты слияния вручную, предварительно обновляя свою ветку через git pull origin main.
Продвинутые практики: Использовал git stash для временного сохранения изменений, git cherry-pick для переноса отдельных коммитов, git bisect для поиска коммита, внесшего баг, и git hooks для автоматизации (например, проверки линтером).

Пример типичной последовательности для задачи:

git checkout -b feature/add-login
git add .
git commit -m "feat(auth): add basic login form"
git push origin feature/add-login
# После code review:
git checkout main
git pull origin main
git merge --no-ff feature/add-login
git push origin main

Ответ 18+ 🔞

А, Гит! Ну это ж, ёпта, моя ежедневная хлеб-соль, без этого вообще нихуя не работает ни один проект. Как будто без рук, честно. Система контроля версий, которая всех нас и спасает, и иногда доводит до белого каления, когда конфликты решать приходится.

Как я с этой штукой общаюсь:

Ветвление: Работаю либо по этому самому Git Flow, либо по упрощёнке — main, develop и кучу feature-веток. Для каждой задачи — своя ветка, для срочных правок — hotfix, для релиза — отдельная. Без этого бардак наступает через пять минут, волнение ебать.
Коммиты: Стараюсь не делать этих мега-коммитов, где «пофиксил всё». Атомарно, блядь. Одна фича — один коммит, с нормальным описанием. Использую Conventional Commits, чтобы потом не охуевать, глядя в историю: feat:, fix:, docs: — сразу понятно, что там внутри.
Слияние: Обычно мержу с --no-ff, чтобы история не упрощалась в одну линию и было видно, где ветка жила. Но если нужна чистая, линейная история, то тогда ребейз. Делаю git rebase на основную ветку, а потом уже --force-push в свою фичевую, но только перед созданием пул-реквеста, а не в общую! Иначе коллеги мне голову оторвут, доверия ебать ноль.
Конфликты: А, это святое! Сталкиваюсь постоянно, особенно когда несколько человек в одном файле ковыряются. Решаю вручную, это как пазл. Главное — сначала обновиться: git pull origin main, чтобы не намерджить себе овердохуища проблем.
Фишки посерьёзнее: git stash — спасатель, когда срочно нужно переключиться, а коммитить не готов. git cherry-pick — чтобы вытащить один конкретный коммит, как изюминку из булки. git bisect — магия, когда ищешь, какой же коммит всё сломал, работает как двоичный поиск. Ну и git hooks для автоматизации, чтобы, например, линтер прогонялся перед коммитом и не давал залить какую-нибудь дичь.

Вот как обычно выглядит моя магия для простой задачи:

git checkout -b feature/add-login
git add .
git commit -m "feat(auth): add basic login form"
git push origin feature/add-login
# После code review:
git checkout main
git pull origin main
git merge --no-ff feature/add-login
git push origin main

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