Каталог решений - Повышаем эффективность разработки правил обмена

Оглавление

• В чем проблема
• Как решить?
  • Git
  • Git flow
  • Продолжаем дальше
  • Gitrules
  • Gitlab
• А где же пример?
  • Устанавливаем Git
  • Устанавливаем OneScript
  • Устанавливаем библиотеку Gitrules
  • Создаем проект Git
  • Подключаем Gitrules к проекту Git
  • Первые изменения commit
  • Последующие изменения правил
  • Подключаем проект Git к удаленному репозиторию на GitLab
  • Git flow?
• Подведем итоги
• Что дальше?

В чем проблема?

• Нет версионирования правил обмена. Доступный способ это делать — копировать правила обмена вручную.
• Групповая разработка правил мало эффективна. Большие трудозатраты на объединение правил.
• Не ведется учет изменений в удобной форме. Нет общего сервиса для просмотра истории изменений.

Как решить?

Для решения проблем, связанных с разработкой и сопровождением правил обмена, можно использовать систему контроля версий Git.

Git

Git — распределённая система управления версиями. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.

Википедия https://ru.wikipedia.org/wiki/Git

Если говорить простыми словами, Git — это консольное приложение, которое умеет отслеживать и фиксировать изменения в файлах. Git хранит данные проекта в виде наборов слепков проекта. При каждом фиксированном изменении (commit) Git сохраняет текущую версию проекта в виде слепка текущего состояния файлов на момент фиксирования изменений. Также Git может хранить несколько версий наборов слепков  — этот механизм называется ветвление.

Более подробно о Git можно прочитать на официальном сайте.

Для локального просмотра изменений я использую Github desktop. Есть и другие клиенты Git, например:

• Sourcetree от Atlassian;
• Visual studio code. В этом редакторе есть функционал по работе с Git;
• Gitahead и т.п.;

Выбор клиента Git дело вкуса и привычек.

Git flow

При помощи подхода git flow можно упорядочить работу с ветками. Для каждого вида работ отводится отдельная ветка. В общих случаях это:

• master — содержит последнюю актуальную рабочую версию проекта;
• feature — ветка для нового функционала. Сливаем изменения в ветку develop;
• develop — содержит все feature. Сливаем изменения в ветки release или master;
• release — ветка с изменениями из develop и hotfix. Сливаем с веткой master;
• hotfix — ветка для исправления ошибок. Сливаем с ветками develop или master;

Всю разработку ведем от ветки develop. Каждое изменение фиксируем как feature (новый функционал) или hotfix (ошибки), в зависимости от ситуации. При внедрении в рабочую систему делаем слияние с веткой master. Более подробнее можно почитать "Шпаргалка по git-flow".

Продолжаем дальше