Как использовать Git Branches & Buddy для организации кода проекта

Эта статья была создана в партнерстве с Бадди . Спасибо за поддержку партнеров, которые делают возможным использование SitePoint.

В этой статье вы узнаете, как настроить конвейеры непрерывной интеграции / развертывания для рабочего процесса ветвления. Мы будем использовать сервисы Buddy CI / CD для настройки конвейеров. Мы будем использовать базовый проект JavaScript, где мы настроим пару веток разработки. Я покажу вам, как автоматизировать тестирование для каждого типа веток. Я также представлю концепцию ветвления рабочих процессов и покажу несколько примеров, которые вы можете использовать в своих проектах.

Предпосылки

Чтобы следовать этому уроку, вам нужны только базовые навыки Node.js. Вы также должны быть знакомы с Git. Вот пара статей, которые помогут вам:

• Git для начинающих
• Git для команд
• Наша книга, Jump Start Git

Чтобы настроить наши конвейеры, нам нужно написать несколько тестов с использованием Jest . Вам не нужно изучать Jest, если вы новичок в этом — цель этой статьи — узнать, как настроить конвейеры, которые будут автоматически выбирать новые ветви и создавать их для вас. Прежде чем мы доберемся до этого, мы должны рассмотреть различные стратегии отрасли, которые мы можем использовать.

Стратегия нулевой ветви

Стратегия нулевого ветвления — просто причудливый способ сказать, что вы не используете какую-либо стратегию ветвления. Она также известна как базовый рабочий процесс. У вас есть только master ветка, где вы непосредственно фиксируете и создаете свои релизы. Эта стратегия удобна и хороша, если проект:

• Маленький и простой
• Вряд ли требует обновления
• Управляется соло разработчиком

К таким проектам относятся учебные пособия, демонстрации, прототипы, шаблоны стартовых проектов и личные проекты. Однако у этого подхода есть несколько минусов:

• Вероятно, возникнут множественные конфликты слияния, если над проектом работает более одного человека
• Вы не сможете разрабатывать несколько функций и исправлять проблемы одновременно.
• Удаление и восстановление функций будет сложной задачей
• Ваша команда будет тратить слишком много времени на решение проблем с управлением версиями вместо того, чтобы работать над новыми функциями

Все эти проблемы могут быть решены путем принятия отраслевой стратегии. Это должно дать вам:

• Возможность работать независимо и вносить изменения в общий репозиторий, не затрагивая членов вашей команды
• Возможность объединить код ваших товарищей по команде с вашими изменениями и быстро разрешить любые конфликты, которые могут возникнуть
• Гарантия того, что стандарты кода поддерживаются и совместная работа проходит гладко, независимо от размера вашей команды

Обращаем ваше внимание, что есть много типов ветвящихся рабочих процессов, которые вы можете выбрать. Вы также можете создать свой собственный рабочий процесс ветки, который лучше всего подходит для вас. Давайте начнем с самой простой стратегии ветвления.

Разработка отраслевой стратегии

В этой стратегии вы создаете долгоживущую ветвь, называемую develop которая работает параллельно с master веткой. Вся работа в первую очередь направлена ​​на develop отрасли. Это безопасное место, где вы можете ввести новый код, который может нарушить ваш проект. Вам понадобится стратегия тестирования , чтобы гарантировать, что вы не внесете ошибок в master ветку при объединении изменений.

Плюсы этого рабочего процесса:

• Прост в реализации
• Основная ветвь остается стабильной и здоровой до тех пор, пока на develop ветке проводится экспериментальная работа
• Исправление может быть внедрено в любое время в master ветке, в то время как функция в настоящее время реализуется

Минусы этого рабочего процесса:

• Несколько функций не могут быть разработаны одновременно
• Только один разработчик (максимум два) может активно работать над проектом
• Удаление и восстановление функций с помощью только ветки develop является сложной задачей.

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

 $ git clone git@github.com:brandiqa/react-parcel-starter.git buddy-demo $ git remote rm origin # Replace `username` with yours $ git remote add origin git@github.com:username/buddy-demo.git $ git config master.remote origin $ git config master.merge refs/heads/master $ git push -u origin master 

 $ npm install $ npm start 

 $ npm install -D jest 

  "scripts": { //... "test": "jest" }, 

 <div> <h1>React Parcel Starter Kit</h1> <p>This page is on master branch!</p> </div> 

 test("Fake Test 1", () => { expect(true).toBeTruthy(); }); 

 npm install npm test 

 npm run build 

 git checkout -b feature/task-1 

 test("Fake Test 2 for Fake Feature", () => { expect(true).toBeTruthy(); }); 

 $ git add . $ git commit -m "Added first feature branch" $ git push -u origin feature/task-1 [feature/task-1 049bef2] Added first feature branch 1 file changed, 4 insertions(+)