Nano Hash - криптовалюты, майнинг, программирование

Ветка Master и Development никогда не синхронизировалась, даже следуя процессу git-flow в битбакете

Я следую модели ветвления git-flow с моим репозиторием, размещенным в облаке Bitbucket.

  • вклады вносятся в feature ветви (ответвления от develop), которые объединяются в develop ветвь через PR
  • when a release is needed:
    1. create a release branch from latest develop;
    2. объединить master в release; (мне нужно будет выполнить этот шаг, как будет объяснено позже)
    3. увеличить номер версии;
    4. объединить release в master через PR.
  • when a hotfix is needed:
    1. create a hotfix branch from latest master;
    2. увеличить номер версии патча
    3. объединить hotfix в master через PR.
  • when a hotfix is done:
    1. create a bugfix branch from latest master;
    2. разрешить множество конфликтов;
    3. объединить bugfix обратно в develop через PR.

Я строго следую вышеуказанным процедурам. Однако master и develop никогда не синхронизируются, даже сразу после выпуска индикатор на странице ветвей Bitbucket Cloud говорит мне, что ветвь master — это «99 коммитов позади разработки» и «11 коммитов раньше разработки».

Каждый раз при выпуске Bitbucket Cloud всегда говорит мне, что две ветки не синхронизированы (даже я не вносил никаких изменений в ветку master после предыдущего выпуска), поэтому я должен выполнить шаг 2 процедур выпуска. выше. Этот шаг становится все сложнее и сложнее, поскольку он продолжает добавлять файлы, которые были удалены из develop (и должны были быть удалены из master) в процессе слияния.

Я не уверен, что я сделал неправильно. Кто-нибудь может предложить?

git bitbucket git-flow
15.06.2020

  • Все ли слияния являются истинными слияниями? Просто проверка.... 16.06.2020
  • @matt Я не уверен, есть ли фальшивое слияние? Я редко использую git cli, я использую графический интерфейс Soucetree и недавно переключился на графический интерфейс Intellij git. Все, что я делал при попытке слияния, это: извлекать ветку, выбирать другую ветку и нажимать «слияние с текущей» в графическом интерфейсе, а затем разрешать конфликты с помощью интерактивного инструмента слияния графического интерфейса. 16.06.2020
  • Но вы не можете сделать это для PR, потому что вы не за своим компьютером. Вы находитесь в веб-интерфейсе пульта дистанционного управления. И это может предложить поддельное слияние. Например, сквош и слияние, предлагаемые github, не являются слиянием. Позвольте мне сказать по-другому: происходит ли коммит слияния с двумя родителями каждый раз, когда вы используете слово «слияние» в истории? 16.06.2020
  • @матовый Ты прав. Для всех PR я всегда использую сквош и слияние с целевой веткой, так как это дает более чистую историю коммитов для целевой ветки... Эммм, так что я думаю, что использование сквош и слияния является проблемой здесь? 16.06.2020
  • Да, точно. Это не дает вам более чистую историю коммитов; это дает вам нет истории коммитов. Ветви остаются отдельными. Следовательно, как вы говорите, вы никогда не синхронизируетесь. 16.06.2020
  • @matt Спасибо, Мэтт. Кажется, я знаю, как это решить. Для всех функций -> разработать PR, я все равно буду выполнять сквош и слияние, поскольку ветки функций являются временными; но для development -> master PR я сделаю истинное слияние, после чего development и master станут синхронизированы. Я прав? 16.06.2020
  • Да. Сквош и слияние очень хороши для своего рода итерации вперед без истории, где, скажем, develop кажется волшебным образом растет шаг за шагом за счет разумных целенаправленных итераций. Если вы работаете над функциональной веткой и выполняете сквош-слияние на develop и принудительно удаляете функциональную ветку, это просто выглядит так, как будто develop развивалась гениально, и никто не стал мудрее. Но для настоящих долгоживущих параллельных ветвей, таких как develop и master, если слияние release в master через PR означает слияние с раздавливанием, release и master просто растут независимо, что является катастрофой. 16.06.2020
  • Сказав это, я лично люблю истинные слияния везде. Мне нравится разветвленная архитектура небольших функциональных ответвлений, которые появляются из разработки и присоединяются к ней позже. Для меня это и есть git flow. 16.06.2020
  • @matt спасибо, я использовал вашу информацию, чтобы составить ответ ниже. Благодарю вас! 16.06.2020
  • О, еще одна вещь (извините, я не хочу ворчать): не делайте PR для слияния develop с master. Этот поезд ушел со станции. Эти коммиты были одобрены; это то, что develop для. Просто слиться. 16.06.2020
  • @matt Да, я никогда не выполнял прямое слияние develop в master, поскольку репозиторий настроен так, чтобы не иметь прямого доступа для записи к обеим ветвям. Это всегда были PR для release-к-master или hotfix-к-master. 16.06.2020
  • Ах, да, есть смысл ставить охрану на свои ветки. 16.06.2020

Ответы:


1

Как отметил @matt в комментариях выше, основная причина того, что ветки develop и master никогда не синхронизируются, заключается в том, что я всегда использовал «сквош и слияние» в PR Bitbucket.

Я только что выполнил выпуск (develop -> release -> master), объединив выпуск PR в master с помощью "явного слияния" (без быстрой перемотки вперед), и теперь ветки develop и master синхронизированы.

Для разных политик слияния, т.е. явное слияние (без перемотки вперед), неявное слияние (с перемоткой вперед) и сквош и слияние, можно обратиться к этой статье Стратегии слияния запросов на включение: большие дебаты для обсуждение различий на высоком уровне. Я нашел GIFs очень полезными.

15.06.2020
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..