Если ты работаешь в IT (или около), скорее всего ты хотя бы слышал про Git — систему контроля версий. А возможно, даже пользуешься ею регулярно.
В предыдущей статье я рассказывал, зачем Git может понадобиться даже аналитику, и как он помогает держать под контролем рабочие документы, требования, пайплайны и задачи.
→ Посмотреть статью «Что аналитику делать с Git»
Но сегодня давай посмотрим с другой стороны.
Git — это не идеальный инструмент. Да, он мощный, гибкий, масштабируемый — но на практике с ним бывают и сложности. Особенно, если ты не разработчик.
1. Порог входа всё ещё высокий
Даже у разработчиков бывает ступор от rebase, merge conflict и прочего веселья.
А если ты аналитик или только начинаешь работать с системами контроля версий, Git может показаться слишком технарским и непонятным. Терминал, команды, ошибки, состояние репозитория — всё это пугает.
На старте Git не прощает невнимательность: одна не та команда — и правки исчезли.
2. Он плохо подходит для хранения тяжёлых файлов
Git создан для текста. Да, Markdown, YAML, код, требования в виде .md — это всё его стихия.
Но если ты решишь залить туда Excel, PDF с графиками или макеты — готовься к конфликтам и тормозам.
Есть обходные решения типа Git LFS, но для обычного пользователя это часто лишняя головная боль. В итоге крупные файлы лучше держать в сторонних хранилищах, а Git использовать только для исходников и документации.
3. Конфликты — неизбежная боль
Работать вдвоём над одним файлом без скоординированного процесса = постоянные конфликты. А разрешение конфликтов в Git — отдельный квест.
Если ты не знаешь, как вручную сравнивать изменения, использовать визуальные дифф-инструменты, и боишься rebase — можно реально поломать историю проекта.
4. Git даёт слишком много свободы
Merge или Rebase? Коммиты отдельные или слиянием?
Git предлагает десятки способов сделать одно и то же — и это сильно сбивает с толку, если нет согласованных практик в команде.
Такой гибкости не хватает чётких рамок. И пока не договорились — каждый работает как умеет, а потом всё ломается.
5. История коммитов может быть бесполезной
В теории, в Git удобно отслеживать изменения: кто, когда, что и зачем.
На практике — коммиты с сообщениями «fix», «123», «баг», «ещё раз попробую» превращают лог изменений в кашу. Разобраться в ней спустя пару месяцев становится невозможно.
А если ещё кто-то делает force push, можно и вовсе потерять важные куски истории.
А где же Mercurial?
Если ты был в IT лет 10 назад, мог застать конкурента Git — Mercurial (hg).
Он был проще, логичнее, дружелюбнее. Даже интерфейс команд был более интуитивным.
Но победила не простота — победила масштабируемость и поддержка крупных экосистем (GitHub, GitLab, Bitbucket). Mercurial остался в прошлом, но его философии многим не хватало.
Что делать?
Git — инструмент, требующий уважения и практики.
Он может многое упростить, но сначала нужно:
- понять его базовую модель,
- договориться в команде о правилах,
- и быть готовым к косякам на старте (это нормально).
Аналитикам Git помогает стать ближе к разработке, улучшить документацию, сократить рассинхрон с командой и упростить внедрение изменений. Но только если подойти к нему с умом.
📩 Как у тебя с Git?
Пугает? Упрощает жизнь? Или ты до сих пор держишь всё в Google Docs и тебе ок?
Напиши в комментариях — разберём типичные ситуации, с которыми сталкиваются аналитики.
📎 Хочешь понять, зачем вообще аналитику Git и как им пользоваться без боли?
Прочти предыдущий лонгрид:
📬 Подпишись, чтобы не пропустить следующий разбор — будет ещё много про системное мышление, ошибки, рост и жизнь в IT без глянца.