Статья серьезная, плевать на название, ха-ха
Git — это основной инструмент контроля версий, но то, как разумно управлять ветвями в процессе разработки программного обеспечения, остается спорным вопросом.
Далее я сравню различия между существующими еще несколькими распространенными методами управления ветками и предыдущим использованием Aone на Али.
Git Flow
Сначала посмотрите на картинку, эта картинка взята изПредложение Винсента в 2010 году, который прекрасно интерпретирует рабочий режим Git Flow.
В качестве шаблона, который предлагался более 10 лет, Git Flow относительно прост.
Есть две стабильные ветки: develop и master. Эти две ветки не будут удалены. Master соответствует стабильной версии, а develop — стабильная версия для ежедневной разработки.
Другие ветви функций, выпусков и исправлений удаляются, как только они израсходованы.
Ветка фич — это ветка разработки для всех.Если есть новые требования, ветку фича нужно вытащить для разработки на основе разработки.
Ветка выпуска — это ветка, используемая для тестирования и выпуска.
хотфикс используется для срочного исправления ошибок.
Процесс разработки выглядит следующим образом:
- Сначала мы создали основную ветку, а затем создали ветку разработки на основе основной ветки.
- Затем A и B одновременно извлекают код на основе определенной версии ветки разработки для разработки, ветки называются feature-A и feature-B соответственно.
- Если вам нужно исправить ошибки в процессе разработки, то вытащите ветку из master и назовите ее hotfix-xxx для исправления.После завершения исправления объедините ее в develop и master, а затем удалите ветку исправления.
- Тогда код A быстрее, и сначала завершается разработка, код ветки feature-A сливается в ветку development, ветка feature удаляется, а затем мы создаем новую ветку release-A на основе ветки development для тестирования
- Если в ходе тестирования будет обнаружена проблема, мы исправим ее в ветке релиза и сольем исправленный код в разработку.
- Release-A после завершения теста и его запуска код объединяется с мастером и разработкой, а ветвь релиза удаляется.
- В это время B, наконец, завершил разработку требований, а затем объединил их в разработку в соответствии с процессом создания нового релиза-B и слияния его с мастером и разработкой.
Это также относительно просто для практических приложений.Для Mac мы можем установить его напрямую наиболее удобным способом.
Сначала установите Git Flow,brew install git-flow-avh, выполнить после установкиgit flow initОн будет инициализирован, вы можете ввести свои имена веток мастера и разработки, а затем установить префикс нескольких других веток по умолчанию.
затем выполнитьgit flow feature start irvingВы можете инициализировать и создать ветку для разработки, по умолчанию мы видим, что она создана на основе разработки.
Если разработка завершена, выполняем командуgit flow feature finish irving, то наша ветка разработки автоматически объединяется с веткой разработки, а ветка разработки удаляется.
Затем нашу ветку нужно протестировать и выпустить, а команду выполнитьgit flow release start irving, если исправляете баг, то исправляйте прямо на этом.
После завершения теста выполните командуgit flow release finish irving, код будет объединен в master и development, а затем ветка будет удалена.
Сказали принцип и способ реализации, так что эта модель по сути та же проблема, то есть больше подходит для итеративной разработки исправленных версий.Это слишком много для бессовестного интернета публиковать каждый день, а нужно более 10 выходить в интернет каждый день.
У меня сегодня 10 требований для ветки разработки, 8 будут онлайн, 2 нет, и код все еще зависит от последовательности и так далее, так что я не могу играть в нее, но он дает лучшую спецификацию и идею.
Github Flow
Github Flow можно сказать очень простой, он был предложен в 2011 году, в основном для Git Flow.
Он основан на основной ветке, которая вытягивает ветку для разработки, а затем разрабатывает новую ветку, отправляет запрос на вытягивание после завершения и объединяет код для развертывания, если он принят.
В частности, вы можете увидетьОфициальное введение.
Этот метод прост и прост, но в процессе развития бизнеса многих компаний обычно существует несколько сред для разработки, тестирования, предварительного выпуска и производства.Я думаю, что без мощных инструментов для его поддержки сложно использовать этот простой модель для достижения управления.
Я думаю, что эта модель особенно подходит для небольших команд с меньшим количеством людей и меньшими потребностями, поэтому она проста.
Trunk-Based
Эта модель была предложена несколько позже, вПредложение, предложенное Полом Хаммантом в 2013 г..
Глядя на картинку в принципе можно понять, что это не модель SVN.Транк разрабатывается, и тянутся новые ветки для разработки и деплоя, исправления багов.
использованная схема
Раньше мы использовали решение, похожее на Git Flow, но полагающееся не на поддержку инструментов, а больше на собственные соглашения и спецификации команды.
Для разработки, тестирования, предварительного выпуска и производства используются ветки разработки, тестирования, выпуска и мастера соответственно.Ветка master является стабильной веткой, и код не может быть отправлен напрямую.В то же время эти ветки являются только фиксированные ветки.
Прежде всего, на этапе разработки всем необходимо создать последнюю ветку разработки функций на основе мастера с именем feature/xxx.
Если вам нужно опубликовать в среде разработки, все коды должны быть объединены в разработку, и вы можете использовать только ветку разработки для выпуска среды разработки.
Если разработка завершена, ветка, которую необходимо протестировать, объединяется с тестовой веткой, а те, которые еще находятся в стадии разработки, разрабатываются.
После завершения теста необходимо выпустить пре-релиз (конечно, его можно назвать градациями серого или uat), а код вливается в релиз для релиза.
После завершения выпуска код автоматически объединяется с мастером.
Преимущество этого заключается в том, что разработка и управление ветками сначала стандартизированы, так что в процессе разработки не будет слишком много споров, и им можно хорошо управлять для нескольких требований, разработанных одновременно и запущенных в разное время.
Недостаток в том, что разрабатывается и запускается несколько требований к проекту, и необходимо объединить несколько кодов, от разработки, тестирования до релиза код должен быть объединен один раз и конфликт разрешен.
В целом это просто командная спецификация, которая не предъявляет слишком много требований к среде и возможностям промежуточного ПО CI/CD, и может быть легко применена к сценариям различных компаний.
Решение Али
Можно сказать, что решение Али представляет собой комбинацию вышеупомянутых режимов, называемых Aone Flow, вероятно, потому, что сам инструмент называется Aone.
Есть только три ветки: основная ветвь, функция ветки и выпуск ветки выпуска.Ветвь выпуска в основном не требует участия разработчиков в управлении.
Прежде всего, создание веток также основано на мастере.Если есть спрос, сначала создайте ветку с функциями.Aone автоматически объединит мастер-код перед развертыванием, поэтому вам не нужно беспокоиться о проблеме, которую код не объединен.Если есть конфликт, его необходимо разрешить вручную, в противном случае он будет автоматически создавать новую ветку для развертывания, эта ветка является веткой выпуска.
Эту ветвь всегда можно использовать для выпуска ежедневных (понимаемых как комбинация сред разработки или тестирования), промежуточных и производственных сред.
Итак, если несколько требований разрабатываются одновременно и возникают конфликты, нужно ли объединять код? Прежде всего, развертывание Aone может одновременно развертывать несколько веток.Если вы решите развернуть несколько веток функций, код будет автоматически объединен.Если есть конфликт, вам нужно решить его вручную.Кроме того, вы можете создать отдельная среда для развертывания, не влияя друг на друга.Эта функция действительно висит.
То же правило применяется к промежуточной и производственной средам.
Во всем процессе разработки нам не нужно управлять различными ветками, нам нужна только одна фича-ветка для публикации каждой среды.После финального релиза код автоматически сливается с основной веткой (опционально, или не сливается).
Весь режим смотрит на интеграцию характеристик каждого режима, ссылаясь на характеристики веток Git Flow, но другие ветки не нуждаются в заботе разработчиков, основанных на главном мастере, чтобы вытащить ветку развития, автоматическое слияние похоже на TrunkBased. подход, и, наконец, весь процесс похож на упрощенную версию Github Flow для разработчиков.
Ссылка на статью: