Skip to content

git.md

Latest commit

 

History

History
258 lines (174 loc) · 12.6 KB

git.md

File metadata and controls

258 lines (174 loc) · 12.6 KB

Git простыми словами для 1С-разработчика

Если вы работали в основном с Хранилищем конфигурации, то Git можно понять так:

  • Хранилище — это одно общее место, куда все складывают изменения.
  • Git — это система, где у каждого разработчика есть своя копия истории изменений на компьютере, и есть общий сервер (GitHub/GitLab/Bitbucket).

Локальный и облачный репозиторий

Локальный репозиторий

Это репозиторий у вас на компьютере.

Зачем нужен:

  • писать код и сохранять изменения даже без интернета;
  • откатываться к старым версиям;
  • делать свои промежуточные шаги (коммиты) без влияния на коллег.

Облачный (удалённый) репозиторий

Это общий репозиторий на сервере (например, GitHub).

Зачем нужен:

  • обмен изменениями между разработчиками;
  • резервное хранение истории;
  • код-ревью через Pull Request;
  • командная работа и контроль качества.

Коротко:

  • локальный — рабочее место разработчика;
  • облачный — общее место для команды.

Что такое коммит

Коммит — это сохранённый снимок изменений с комментарием.

Пример: вы исправили ошибку в отчёте и сделали коммит с текстом Исправил расчет НДС в отчете продаж.

Важно:

  • коммиты лучше делать небольшими и понятными;
  • по истории коммитов удобно понимать, кто и зачем что менял;
  • при проблеме проще найти нужный момент и откатиться.

Отдельный плюс при работе с ИИ-агентом:

  • агент обычно хорошо предлагает текст коммита по смыслу изменений;
  • но перед подтверждением всё равно полезно быстро прочитать сообщение.

Статусы файлов: черновик → подготовлено → сохранено

Чтобы проще запомнить, смотрите как на три этапа:

  1. modified — «черновик»

    • вы изменили файл, но Git ещё не знает, что именно хотите включить в коммит.

  2. staged — «подготовлено»

    • вы выбрали изменения, которые точно пойдут в следующий коммит.

  3. committed — «сохранено»

    • изменения уже записаны в историю Git как отдельный шаг.

Короткая цепочка: изменил файл → добавил в stage → сделал commit.

Pull / Push простыми словами

  • git pull — «забрать» изменения с сервера в локальный репозиторий.
  • git push — «отправить» свои локальные коммиты на сервер.

Простое правило:

  • перед началом задачи обычно делают pull, чтобы работать на свежей версии;
  • после коммитов делают push, чтобы изменения увидела команда.

Что такое ветка

Ветка — это отдельная линия разработки.

Обычно есть:

  • main (или master) — стабильная основная версия;
  • рабочие ветки под задачи, например feature/add-vat-report.

Зачем это нужно:

  • можно делать новую задачу, не ломая основную версию;
  • несколько человек могут работать параллельно;
  • изменения попадают в основную ветку только после проверки.

Аналогия с 1С: ветка — как отдельная копия для доработки, которую потом аккуратно вливают в общую.

PR (Pull Request)

Pull Request (PR) — это запрос: «Проверьте мои изменения и влейте их в основную ветку».

В PR обычно:

  • описание, что сделано и зачем;
  • список коммитов;
  • обсуждение и замечания от коллег;
  • автоматические проверки (тесты, линтеры, проверки CI).

То есть PR — это не просто техническая кнопка, а этап командной проверки качества.

Merge (мерж)

Merge — это объединение веток.

Пример:

  1. Вы сделали задачу в своей ветке.
  2. Открыли PR.
  3. После проверки PR одобрили.
  4. Вашу ветку слили (merge) в main.

После merge изменения становятся частью основной версии проекта.

Конфликты при слиянии

Конфликт — это ситуация, когда Git не может автоматически понять, какую версию оставить.

Почему возникает чаще всего:

  • два человека изменили одни и те же строки;
  • вы долго работали в ветке и она сильно разошлась с main.

Общий принцип решения:

  1. Git показывает конфликтные файлы.
  2. Вы вручную выбираете правильный вариант (или объединяете оба).
  3. Проверяете, что код/логика работает.
  4. Подтверждаете исправление и завершаете merge.

Важно: конфликт — это нормально, это не «поломка Git», а рабочая часть командной разработки.

Ключевые роли в работе с Git

Git сам по себе не назначает роли, но в команде обычно есть такие:

  1. Разработчик (Author)

    • делает изменения;
    • создаёт коммиты;
    • открывает PR.

  2. Ревьюер (Reviewer)

    • проверяет PR;
    • ищет ошибки и спорные места;
    • предлагает улучшения;
    • даёт одобрение.

  3. Интегратор / мейнтейнер (Maintainer)

    • отвечает за целостность основной ветки;
    • решает, когда и как мержить изменения;
    • следит за правилами репозитория.

Иногда все эти роли может выполнять один человек, в маленькой команде это нормально.

Минимальный рабочий процесс

  1. Забрать свежую версию проекта (pull).
  2. Создать свою ветку под задачу.
  3. Внести изменения.
  4. Сделать один или несколько осмысленных коммитов.
  5. Отправить ветку в облачный репозиторий (push).
  6. Открыть PR.
  7. Пройти ревью и правки.
  8. Сделать merge в main.

Такой процесс помогает не терять изменения, не ломать общую версию и прозрачно работать в команде.

Коммит как чек-поинт (точка возврата)

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

  1. Сначала сделать «безопасный» коммит текущего состояния.
  2. Потом запускать агента или делать крупные правки.
  3. Если что-то пошло не так — вернуться к этому коммиту.

То есть коммит работает как чек-поинт в игре: можно вернуться на сохранение.

Как сделать чек-поинт

Обычно перед экспериментом делают коммит с понятным текстом, например:

  • checkpoint: перед автоправками агента
  • checkpoint: стабильное состояние перед рефакторингом

Важно: такой коммит лучше делать в своей рабочей ветке.

Как откатиться к чек-поинту

Есть два простых безопасных варианта:

  1. Через git revert (рекомендуется для общей ветки)

    • создаётся новый коммит, который отменяет неудачные изменения;
    • история остаётся прозрачной;
    • удобно, если изменения уже ушли в удалённый репозиторий.

  2. Через git reset --hard <commit> (только для локальной, личной работы)

    • ветка «перематывается» назад к выбранному коммиту;
    • все более поздние незакреплённые изменения удаляются;
    • удобно, если нужно быстро вернуть локальное состояние.

Практическое правило:

  • если сомневаетесь — выбирайте revert;
  • reset --hard используйте только когда точно понимаете последствия.

Типичные ошибки новичков

  • Работают сразу в main, а не в отдельной ветке.
  • Делают один очень большой коммит «сразу за всё».
  • Забывают сделать pull перед началом задачи.
  • Пушат без самопроверки и без PR.
  • Пишут непонятные сообщения коммитов вроде fix, upd, правки.
  • Пытаются решать конфликт «наугад», не проверив итоговый результат.

Как это связано с этим фреймворком

Если вы работаете через агент в этом проекте, Git-процесс остаётся тем же, но часть рутины берёт на себя агент:

  • помогает формировать понятные коммиты;
  • следит за рабочей веткой и аккуратным workflow через PR;
  • подсказывает безопасные действия при конфликтах и откатах.

Полезные материалы проекта:

Главное запомнить

  • Коммит = сохранённый шаг изменений.
  • Ветка = отдельная линия работы.
  • PR = запрос на проверку и вливание изменений.
  • Merge = объединение веток.
  • Локальный репозиторий = ваша рабочая копия.
  • Облачный репозиторий = общее место команды.

Если коротко: Git делает командную разработку управляемой и безопасной.