В этой статье представлены практические возможности git, которыми архитекторы должны овладеть с точки зрения фронтенд-инжиниринга, совместной работы в команде и производственного развертывания.
Предварительный просмотр схемы
Содержание, представленное в этой статье, включает следующие аспекты:
- Стратегия управления филиалом
- спецификация фиксации и проверка фиксации
- Неправильное использование плана вывода
- Тег и производственная среда
- Навсегда устранить 443 Timeout
- Крюк для достижения развертывания?
- Идеальное приложение: CI/CD
Стратегия управления филиалом
Ветки Git мощные и в то же время гибкие.Если нет хорошей стратегии управления ветками, члены команды будут сливаться и пушить по своему желанию, что вызовет путаницу веток, различное покрытие, конфликты, потери и другие проблемы.
В настоящее время наиболее популярная стратегия управления филиалом, также известная как рабочий процесс (Workflow), в основном включает в себя три типа:
- Git Flow
- GitHub Flow
- GitLab Flow
Наша фронтенд-группа сформулировала собственный набор стратегий управления филиалом, исходя из реальной ситуации.
Мы делим филиалы на 4 широкие категории:
- dev-*
- develop
- staging
- release
dev-*Это собирательное название для группы веток разработки, включая персональные ветки, ветки модулей, ветки ремонта и т. д., и на этой группе веток работают разработчики команды.
Перед разработкой пройтиmergeСлейте последний код из ветки разработки, когда разработка будет завершена, вы должны пройтиcherry-pickсливаться обратноdevelopветвь.
developЭто отдельная ветка, соответствующая среде разработки, содержащая последний и полный код разработки. он принимает толькоcherry-pick, слияние не допускается.
stagingВетки соответствуют тестовым средам. Когда в ветке разработки есть обновление и она готова к выпуску теста, подготовка проходит.rebaseОбъедините ветку разработки и опубликуйте последний код на тестовом сервере для тестирования тестировщиков.
После того, как тест найдет проблему, перейдитеdev-* -> develop -> stagingобрабатывать до тех пор, пока тест не будет пройден.
releaseпредставляет производственную среду. Последние коммиты ветки релиза всегда синхронизируются с рабочим кодом, то есть ветка релиза готова к выпуску в любое время.
Когда промежуточный тест проходит,releaseразветвление черезrebaseОбъедините промежуточную ветку и опубликуйте последний код на рабочем сервере.
Подводя итог правилам слияния:
- develop -> (merge) -> dev-*
- dev-* -> (cherry-pick) -> develop
- develop -> (rebase) -> staging
- staging -> (rebase) -> release
Почему слияние с разработкой должно быть тщательным?
Используйте слияние для слияния, если есть конфликт, будет создан форк;dev-*Есть много сложных ветвей, и прямое слияние для разработки приведет к сложным разветвлениям, что затруднит сортировку хода отправки.
И Cherry-Pick только сливает нужные коммиты в ветку develop, а не генерирует форки, так что график git commit (git graph) всегда будет поддерживать прямую линию.
Кроме того, после завершения ветки разработки модулей несколько коммитов необходимо объединить в один коммит, а затем объединить в ветку разработки, чтобы избежать избыточных коммитов, что является одной из причин, по которой слияние не требуется.
Почему необходимо использовать rebase для слияния с промежуточной/выпускной версией?
Rebase транслируется в rebase, а слияние также не приводит к разветвлениям. При разработке обновлений многие функции должны быть объединены в промежуточные тесты, невозможно выбирать коммиты один за другим. Поэтому его нужно слить за один раз через rebase, и гарантируется полная синхронизация стейджинга и разработки.
То же самое относится и к релизу: после того, как тест пройден, используйте rebase для одновременного слияния staging, что также гарантирует полную синхронизацию staging и релиза.
спецификация фиксации и проверка фиксации
Спецификация фиксации относится к информации описания, заполняемой при фиксации git, которая должна соответствовать унифицированной спецификации.
Только представьте, если коммиты членов команды заполняются по желанию, при совместной разработке и ревью кода другие люди понятия не имеют, какую функцию выполнил этот коммит или какая ошибка была исправлена, и трудно контролировать прогресс.
Чтобы визуально видеть обновленное содержимое коммитов, сообщество разработчиков создало спецификацию, которая делит коммиты по их функциям и добавляет некоторые фиксированные префиксы, такие какfix:,feat:Что в основном сделал этот COMMIT.
Текущие основные префиксы включают следующие части:
-
build: Указывает сборку, версия выпуска доступна с этим -
ci: Обновление конфигурации автоматизации, такой как CI/CD. -
chore: Разное, другие изменения -
docs: обновить документацию -
feat: Обычно используется, указывая на новые функции. -
fix: Common: указывает на исправление ошибок -
perf: оптимизация производительности -
refactor: рефакторинг -
revert: откат кода -
style: изменение стиля -
test: изменения модульного теста
Эти префиксы нужно писать каждый раз, когда они отправляются, и многие люди до сих пор не могут их запомнить в начале. Здесь рекомендуется очень полезный инструмент, который может автоматически генерировать префиксы. адрес вздесь
Сначала установите глобально:
npm install -g commitizen cz-conventional-changelog
Создайте~/.czrcфайл, напишите следующее:
{ "path": "cz-conventional-changelog" }
теперь доступноgit czкоманда вместо этогоgit commitкоманда, эффект следующий:
Затем стрелками вверх и вниз выберите префикс, и вы сможете легко создать отправку, которая соответствует спецификации в соответствии с подсказками.
После того, как спецификация составлена, недостаточно полагаться на сознательное соответствие людей, и представленная информация должна быть проверена в процессе.
В это время нам нужно использовать новую вещь -git hook, также известные как git-хуки.
Роль git-хука состоит в том, чтобы запускать пользовательские скрипты до и после выполнения действий git. Эти действия включают фиксацию, слияние, отправку и т. д. Мы можем использовать эти хуки для реализации нашей собственной бизнес-логики во всех аспектах процесса git.
Крючки Git делятся на хуки на стороне клиента и хуки на стороне сервера.
Есть четыре основных клиентских крючка:
-
pre-commit: запустить перед отправкой информации, чтобы проверить код в промежуточной области -
prepare-commit-msg: редко используется -
commit-msg: очень важно, используйте этот хук для проверки информации о коммите -
post-commit: запустить после завершения фиксации
Серверные хуки включают в себя:
-
pre-receive: Очень важно, здесь есть различные проверки перед пушем -
post-receive: редко используется -
update: редко используется
Большинство команд выполняют проверку на стороне клиента, поэтому мы используемcommit-msgХук проверяет информацию фиксации на стороне клиента.
К счастью, нам не нужно вручную писать логику проверки, и у сообщества есть зрелые решения:husky + commitlint
husky — это артефакт для создания клиентских хуков git, а commitlint — для проверки того, соответствует ли информация фиксации указанным выше спецификациям. Комбинация этих двух факторов может предотвратить создание коммитов, не соответствующих спецификации фиксации, и обеспечить соответствие спецификации фиксации исходному коду.
Пожалуйста, смотрите конкретное использование husky + commitlintздесь
Неправильное использование плана вывода
Частое использование git для извлечения и отправки кода в процессе разработки неизбежно приведет к неправильной работе. Не паникуйте на данный момент, git поддерживает схему вывода большинства сценариев, подытожим.
Есть две основные команды для вывода:resetа такжеrevert
git reset
Принцип команды сброса основан наcommitIdдля восстановления версии. Поскольку каждая фиксация генерирует идентификатор commitId, сброс может помочь вам вернуться к любой версии в истории.
Вот версия представления и смысла, это версия commitId
Формат команды сброса следующий:
$ git reset [option] [commitId]
Например, чтобы выйти на фиксацию, команда будет такой:
$ git reset --hard cc7b5be
Как в приведенной выше команде получается commitId? очень просто, используйтеgit logКоманда для просмотра записи фиксации, вы можете увидеть значение commitId, это значение очень длинное, мы можем просто взять первые 7 цифр.
Вариант здесь--hard, на самом деле есть 3 значения, конкретные значения таковы:
-
--hard: отменить фиксацию, отменить добавление, удалить код изменения рабочей области -
--mixed: параметр по умолчанию. Отменить фиксацию, отменить добавление, восстановить код изменения рабочей области -
--soft: отменить фиксацию, не отменять добавление, восстановить код изменения рабочей области
Обратите особое внимание здесь--hard, восстановление с этим параметром приведет к удалению кода рабочей области. То есть, если в вашем проекте есть незафиксированный код, использование этого параметра удалит его напрямую, его нельзя восстановить, будьте осторожны!
В дополнение к возврату с помощью commitId, git reset также предоставляет ярлык для возврата к последнему коммиту:
$ git reset --soft HEAD^
HEAD^Указывает на предыдущую фиксацию, может использоваться несколько раз.
На самом деле, самая распространенная ошибка в ежедневной разработке заключается в следующем: сразу после отправки внезапно обнаружилась проблема, например, информация о представлении написана неправильно или отсутствует изменение кода, тогда вам нужно вернуться к последнему представлению, изменить код, а затем повторите отправку.
Процесс примерно такой:
# 1. 回退到上次提交
$ git reset HEAD^
# 2. 修改代码...
...
# 3. 加入暂存
$ git add .
# 4. 重新提交
$ git commit -m 'fix: ***'
Для этого процесса git также предоставляет более удобный метод:
$ git commit --amend
Эта команда напрямую изменит текущую информацию о коммите. Если код изменился, выполнить сначалаgit add, а затем выполните эту команду, которая быстрее и удобнее, чем описанный выше процесс.
Еще одной важной особенностью сброса является то, чтоДействительно отступите на одну версию.
Что это значит? Например, вы отправили текущую фиксацию в удаленный репозиторий; теперь вы используете reset для отмены фиксации, а локальный репозиторий git на одну версию отстает от удаленного репозитория. В этот момент, если вы снова нажмете, удаленный репозиторий отклонит его и попросит вас сначала выполнить извлечение.
Если вам нужно, чтобы удаленный репозиторий также откатил версию, вам нужно-fпараметр, принудительно нажмите, тогда локальный код перезапишет удаленный код.
Уведомление,-fПараметры очень опасны! Если вы не очень хорошо знакомы с принципами git и командной строкой, не используйте этот параметр.
Как может быть безопаснее отозвать код предыдущей версии и синхронизировать его с удаленным?
Решением является вторая команда, которая будет произнесена ниже:git revert
git revert
Функции возврата и сброса аналогичны восстановлению версии, но реализованы они по-разному.
Проще говоря, reset напрямую восстанавливает предыдущий коммит, а код рабочей области, естественно, является кодом из предыдущего коммита, тогда как revert добавляет новый коммит, но этот коммит использует код из предыдущего коммита.
Таким образом, два восстановленных кода одинаковы, разница заключается в новой фиксации (возврат) и фиксации отката (сброс).
Просто потому, что при возврате всегда добавляются новые отправки, версия локального хранилища никогда не может быть позади удаленного хранилища и может быть отправлена непосредственно в удаленный склад, поэтому после решения сброса необходимо добавить отправку.-fпроблемы с параметрами, повысить безопасность.
Поговорив о принципе, давайте посмотрим, как его использовать:
$ git revert -n [commitId]
Его очень просто использовать после освоения принципа, достаточно одного commitId.
Тег и производственная среда
Git поддерживает тег tag для коммита в истории, который часто используется для идентификации важных обновлений версии.
В настоящее время общепринятой практикой является использование тегов для указания версии рабочей среды. Когда последний коммит проходит тесты и готов к выпуску, мы можем создать тег, указывающий, что производственная версия будет выпущена.
Например, я хочу отправитьv1.2.4версия:
$ git tag -a v1.2.4 -m "my version 1.2.4"
Затем вы можете просмотреть:
$ git show v1.2.4
> tag v1.2.4
Tagger: ruims <2218466341@qq.com>
Date: Sun Sep 26 10:24:30 2021 +0800
my version 1.2.4
Наконец, отправьте тег на пульт с помощью git push:
$ git push origin v1.2.4
Обратите внимание здесь:tag не имеет ничего общего с тем, в какой ветке он был создан, tag — это просто псевдоним для коммита. Следовательно, можно использовать тег возможности фиксации, например, приведенный выше.git reset,git revertЗаказ.
Когда возникает проблема в рабочей среде и требуется откат версии, можно сделать так:
$ git revert [pre-tag]
# 若上一个版本是 v1.2.3，则：
$ git revert v1.2.3
В хранилище с частыми обновлениями и большим количеством коммитов, очевидно, чище и читабельнее использовать теги для идентификации версий.
Подумайте о полезности тега под другим углом.
Как упоминалось выше в разделе о стратегии управления ветвями, релизная ветвь синхронизируется с производственным кодом. В процессе непрерывного развертывания CI/CD (описанного ниже) мы прослушиваем ветку выпуска для отправки и запускаем автоматические сборки.
Можно ли прослушать нажатие тега, а затем запустить автоматическую сборку, чтобы интуитивность обновления версии была лучше?
Есть много вариантов использования, которые следует учитывать.
Навсегда устранить 443 Timeout
Репозиторий кода в нашей команде — GitHub, По известным причинам GitHub извлекает и выталкивает очень медленно и даже сообщает об ошибке: 443 Timeout.
План, с которого мы начали, состоял в том, чтобы включить VPN для всех сотрудников. Хотя в большинстве случаев скорость хорошая, бывают часы или даже дни, когда код не может быть загружен, что серьезно влияет на ход разработки.
Позже я вдруг подумал, что медленный тайм-аут из-за стены, например, домашняя страница GitHub не может быть открыта. Глядя на основную причину, стена — это протокол http или https при доступе к веб-сайту, поэтому другие протоколы не будут иметь стены?
Делайте это, когда думаете об этом. Мы нашли GitHub в дополнение к дефолтномуhttpsпротокол, также поддерживаетsshпротокол. Итак, готовы попробовать клонировать код по протоколу ssh.
Одной из наиболее неприятных вещей при использовании протокола ssh является настройка входа без пароля, в противном случае вам нужно будет вводить пароль учетной записи каждый раз, когда вы тянете/нажимаете.
Официальная документация GitHub по настройке SSH находится по адресуздесь
Студенты, которые борются с английским языком, могут видетьздесь
Короче говоря, после создания открытого ключа откройте домашнюю страницу GitHub и нажмитеAccount -> Settings -> SSH and GPG keys -> Add SSH key, а затем вставьте в него открытый ключ.
Теперь клонируем код с протоколом ssh, пример такой:
$ git clone git@github.com:[organi-name]/[project-name]
Обнаружил, что он был клонирован в одно мгновение! Пробуйте тянуть/толкать еще несколько раз, и скорость полетит!
Независимо от того, какие платформы управления кодом вы используете, если вы столкнулись с 443 проблемами времени ожидания, пожалуйста, попробуйте протокол SSH!
Крюк для достижения развертывания?
Использование git hook для реализации развертывания должно быть расширенным применением хука.
Сейчас есть много инструментов, таких как GitHub и GitLab, которые обеспечивают функцию непрерывной интеграции, то есть отслеживают пуши определенной ветки, а затем запускают автоматическое построение и автоматическое развертывание.
На самом деле, сколько бы хитростей ни было в этих инструментах, основные функции (прослушивание и сборка) по-прежнему предоставляются git. Просто основные функции лучше интегрированы с собственной платформой.
Сегодня мы отложим в сторону эти инструменты, отследим источник и воспользуемся чистым git для реализации автоматического развертывания реактивного проекта. Освоение этой основной логики делает непрерывное развертывание на любой другой платформе менее загадочным.
Как и часть этой части, поэтому снос в одиночку из статьи по следующему адресу:
Git достичь чистого интерфейса CI / CD
Идеальное приложение: CI/CD
В некоторых из вышеперечисленных мест также упоминались слова «непрерывная интеграция» и «непрерывное развертывание». Теперь главный герой официально дебютировал!
Можно сказать, что все правила спецификации, написанные выше, предназначены для лучшего проектирования и реализации этого главного героя --- CI/CD.
Прежде всего, что такое CI/CD?
Основная концепция CI (Continuous Integration) переводится в непрерывную интеграцию, CD включает в себя две части, непрерывную доставку (Continuous Delivery) и непрерывное развертывание (Continuous Deployment).
С глобальной точки зрения CI/CD — этоавтоматизированный процессСпособ частой доставки приложений клиентам. Этот процесс проходит через весь жизненный цикл интеграции, тестирования, доставки и развертывания приложения и в совокупности называется «конвейером CI/CD».
Хотя оба они представляют собой автоматизированные конвейеры, подобные сборочным линиям, CI и CD имеют свое собственное разделение труда.
Непрерывная интеграциязаключается в частой интеграции кода в основную ветку. При отправке нового кода сборка и тестирование будут выполняться автоматически, и если тест пройден, он будет автоматически объединен с основной ветвью, что обеспечивает быструю итерацию продукта при сохранении высокого качества.
непрерывная поставкаЭто частая доставка новых версий программного обеспечения группе контроля качества или пользователям для проверки. После прохождения проверки рабочая среда может быть выпущена. Непрерывная доставка требует, чтобы код (последний коммит в ветке) был в состоянии готовности к выпуску.
Непрерывное развертываниеПосле того, как код проходит проверку, он автоматически развертывается в производственной среде. Для непрерывного развертывания требуется, чтобы код (последняя фиксация в ветке) был готов к развертыванию.
Единственная разница между непрерывным развертыванием и непрерывной доставкой заключается в шаге развертывания в производственной среде.Это автоматизировано.
Автоматизация развертывания может показаться небольшим шагом, но на практике вы обнаружите, что это самая сложная часть конвейера CI/CD для реализации.
Почему? Во-первых, от непрерывной интеграции до непрерывной доставки все эти связи реализуются командой разработчиков. Мы сотрудничали в команде, чтобы создать новую версию приложения, которое будет выпущено.
Однако развертывание приложения на сервере — это работа группы эксплуатации. Если мы хотим внедрить развертывание, нам нужно общаться с командой эксплуатации и обслуживания.Однако студенты-разработчики не понимают сервер, а студенты-эксплуататоры и специалисты по обслуживанию не понимают код, поэтому общаться сложно.
Кроме того, эксплуатация и обслуживание — это ручное развертывание.Если мы хотим добиться автоматического развертывания, мы должны иметь права доступа к серверу и взаимодействовать с сервером. Это тоже большая проблема, потому что операционная команда должна заниматься вопросами безопасности, поэтому продвижение тормозится.
В настоящее время в сообществе есть много зрелых решений CI/CD, таких как старые.jenkins, используется реакциейcircleci, и то, что я думаю, работает лучше всегоGitHub ActionПодождите, мы можем получить доступ к этим программам в вашей собственной системе.
Эта статья уже довольно длинная, так что давайте закончим ее здесь. Далее я напишу подробную практику CI/CD для фронтенд-проекта React на основе GitHub Action.
Если эта статья была вам полезна, пожалуйстаНравится без колебаний, это моя самая большая поддержка.
я хочу узнать больше
Чтобы лучше защитить оригинальность, я создам публичный аккаунт WeChat для будущих статей.передний конец дровосек. Эта официальная учетная запись выполняет только оригинальную работу, по крайней мере, с одной высококачественной статьей в неделю, и направлением является проектирование и архитектура интерфейса, исследование границ интерфейса на уровне BFF, а также практика и мышление, такие как интегрированная разработка и доставка. .
Кроме того, я также создал группу WeChat для обмена и обучения студентов, заинтересованных в этом направлении. В группе большие фабричные боссы, боги Наггетс 6 уровня и еще студенты, которые хотят изучать это направление.Давайте общаться и делиться учебой вместе~
Если вы также заинтересованы и хотите узнать больше, добавьте меня в WeChat.ruidocПриглашаю вас в группу~