git pull день предотвращает конфликты

В мире открытого исходного кода поддержка активного репозитория или пополнение его не так проста, как кажется, и конфликт слияния — это то, с чем приходится сталкиваться всем, но никому это не нравится. B̶u̶t в Felvin, w̶e̶ ̶l̶o̶v̶e̶ ̶m̶e̶r̶g̶e̶ ̶c̶o̶n̶f̶l̶i̶c̶t̶s это не сильно отличалось.

Этот пост расскажет вам о следующем:

  • Felvin и мгновенные приложения
  • Структура мгновенных приложений
  • Создание мгновенного приложения
  • Объединить конфликты, с которыми мы сталкиваемся
  • Автоматизация и разрешение конфликтов слияния

Felvin и мгновенные приложения

Felvin, радикально мощный способ поиска информации, достигаемый за счет преобразования всего, что вы видите в поисковых системах, в плагин.

Чтобы узнать больше о Felvin и о том, как работает Felvin, нажмите здесь.

Приложения с мгновенным запуском – это небольшие интерактивные карточки, которые вы получаете по своим поисковым запросам. Мы можем создавать мгновенные приложения для всех видов использования, таких как словари, проверка футбольных результатов, цены на акции или заметки из вашего представления или даже история поиска из компании Slack или что-то еще! Нажмите здесь, чтобы узнать больше!

Состав

Как следует из названия, мгновенные приложения — это набор приложений, созданных с помощью сообщества разработчиков открытого исходного кода, и песочница для тестирования этих приложений в одном репозитории.

Мы достигаем этого, создавая отдельные реагирующие приложения, а затем экспортируя все приложения в одно реагирующее приложение в виде узловых модулей.

Ниже представлена ​​структура папок репозитория. Приложения, созданные сообществом, находятся под apps/, например: app1 и app2.
Каждое из этих приложений имеет свои собственные package.json , App.jsx и index.ts .

packages/apps импортирует все приложения, а затем помогает экспортировать их в песочницу.

packages/apps/src/index.ts:

packages/apps/package.json:

И, наконец, файл yarn.lock выглядит примерно так:

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

Создание мгновенного приложения

Новое мгновенное приложение можно создать, запустив yarn create-app .

Создание нового приложения приведет к следующему:

И обновите ./packages/apps/src/index.ts , ./packages/apps/package.json и ./yarn.lock

Объединить конфликты

Из создания нового приложения мы знаем, что несколько файлов (3, если быть точным) обновлены, и они обычно являются виновниками конфликтов слияния.

Давайте посмотрим на пример, чтобы понять это лучше.

На диаграмме ниже показано, как мы обычно сталкиваемся с конфликтами слияния.

Мы создаем новую ветку и начинаем работать над App2 v1.0.0 сразу после выпуска App1 v1.0.0. Пока мы работаем над App2, появилась новая версия App1 — v1.0.1.

Кто-то еще создает новую ветку для App3 v1.0.0 с момента выпуска App1 v1.0.1, и ему удается закончить свое приложение раньше нас. Итак, их ветка сливается с веткой masterперед нашей.

Когда мы, наконец, закончим с App2 v1.0.0 и будем готовы к слиянию с веткой master, мы столкнемся со следующими конфликтами слияния, и в этом есть закономерность:

1. /packages/apps/src/index.ts

В файле index.ts конфликт не такой сложный. Это можно решить, приняв как текущие, так и входящие изменения, но для решения этой проблемы нам потребуется использовать регулярное выражение или текстовый редактор.

2. packages/apps/package.json

В случае с package.json все обстоит совсем иначе. Это немного сложнее, так как задействованы версии приложения. У Git есть опции для принятия входящих ( — theirs) и текущих ( — ours) изменений на основе файлов, но для нас это бесполезно.

3. yarn.lock

Подобно package.json , yarn.lock также содержит конфликтующие версии приложения, но если package.json устранено, то просто запуск yarn или yarn install устранит конфликты.

На этом этапе мы могли бы перебазировать, а затем попытаться объединить его, но перебазирование — плохая идея. Почему это плохая идея, вы можете прочитать здесь.

…вы можете быть уверены, что настоящая история будет полезнее, чем переписанная (или поддельная).

-Фредрик В. Мёркен

Автоматизация и разрешение конфликтов слияния

Чтобы автоматизировать процесс слияния и разрешения конфликтов, мы решили использовать комбинацию Python и оболочки. Встроенных библиотек Python, таких как glob, os и json, было более чем достаточно. Мы также использовали шаблонный код из ./packages/apps/src/index.ts и ./packages/apps/package.json в качестве констант.

Чтобы решить конфликты слияния, лучший способ здесь — сгенерировать ./packages/apps/src/index.ts и ./packages/apps/package.json с нуля, перебирая все приложения в репозитории и получая имя и версию этих приложений. Мы написали класс, чтобы сделать то же самое. Во-первых, мы инициализируем кучу вещей, связанных с получением пути каждого приложения, и это package.json, ./packages/apps/src/index.ts и ./packages/apps/package.json.

Затем мы перебираем package.json каждого приложения, чтобы получить имя и версию.
Чтобы вам было легче следить, с этого момента будут предоставляться комментарии, чтобы лучше показать, что происходит на каждом шаге.

1. Решение './packages/apps/src/index.ts'

2. Решение './packages/apps/package.json'

3. Решение 'yarn.lock'

Как обсуждалось ранее, создание yarn.lock требует от нас только запуска yarn или yarn install сразу после разрешения двух других файлов. Для этого мы:

a) Сначала получите имя текущей ветки
b) Затем запустите git merge master, который остановится перед слиянием, так как возникнут конфликты.
c) Запустите yarn или yarn install
d) Поместите все files
e) Завершите слияние с сообщением слияния по умолчанию, мы также могли бы продолжить слияние с флагом --continue, но это потребовало бы от нас изменения журналов слияния и редактирования их через vim.

Актуальный код можно посмотреть здесь.

Краткое содержание

Конфликты слияния иногда могут быть болезненными, но если вы обнаружите повторяющиеся шаблоны с конфликтами, вы, вероятно, сможете их приручить или сделать своим приятелем, автоматизировав. Этот пост не предназначен для того, чтобы помочь массам, но предназначен для регистрации моего опыта или, возможно, даже для поиска идей для тех, кто сталкивается с чем-то отдаленно похожим, потому что, когда мы пытались найти способ решить наши конфликты слияния, мы не могли найти многого. . Единственный вопрос, который вам нужно задать себе, это "Есть ли закономерность в наших конфликтах слияния?"

Особая благодарность Harsh Gupta за то, что он подтолкнул меня к написанию этого блога.