Правильный способ управления веткой длинных функций, которая может потребовать нескольких действий по перебазированию? - PullRequest
0 голосов
/ 31 августа 2018

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

  • сделать элементную ветку
  • делай работу
  • перебазироваться
  • запрос push и file pull
  • все хорошо, верно? неправильно! Менеджер интеграции отклоняет вашу функцию с комментариями
  • сделать ремонт вашей функции
  • Тем временем мастер ушел, поэтому вы снова делаете перебаз ...
  • упс! теперь вы перебираете ветку, которая уже была нажата!

Как правильно справиться с этим?

1 Ответ

0 голосов
/ 31 августа 2018

" вы не должны публиковать изменения на пульте дистанционного управления до тех пор, пока вы не перезагрузите "

Я полностью не согласен с этим утверждением; ничто из того, что вы описываете, не должно требовать перебазирования.

Проблема, которую вы описываете, заставляет это звучать так, как будто у вас only есть ветвь master на вашем пульте, и что вы разветвляли ветки функций от этого. Это идет против Git Flow .

Не беспокойтесь о длительных ветвях функций - это совершенно нормально, и вы прекрасно можете многократно выдвигать такую ​​ветвь до origin. Это даже рекомендуется из-за резервного копирования в Git (который вы упомянули).

Вы хотите следовать типичному Git Flow:

  1. У вас есть master ветвь, подключенная к вашей производственной среде,
  2. Вы отделяете develop от своей master ветви
    (и подключаете это к средам разработки и тестирования).
  3. Вы ветвите каждое из ваших feature ответвлений от develop, а не master,
  4. В любое время, независимо от того, завершена функция или нет, вы делаете коммит на origin/feature/your-branch,
  5. Когда эта функция будет завершена, вы объединяетесь с develop посредством запроса на извлечение.
    ЭТО - единственное место, где могут возникнуть конфликты!
    • Если есть конфликты, вы исправляете их в своей локальной ветви, pull вставляя ветку develop в свою локальную ветку функций. Вам может понадобиться stash ваши изменения в первую очередь. Затем вы можете push свой локальный филиал вернуться к origin - ветвь функции еще не будет объединена.
    • После разрешения конфликтов ветвь объединяется в develop.
  6. develop затем развертывается в вашей среде разработки (предпочтительно автоматически через инструмент непрерывной интеграции, такой как Jenkins или TeamCity). Таким образом, среда разработки всегда имеет все новейшие функции.

Feature branches

  1. После того, как вы тщательно протестировали свои функции, вы создаете сокращение выпуска функций и выпускаете эту версию до master (которая развернута в рабочей среде). На этом этапе также полезно добавить tag в ветку, чтобы вы точно знали, какая версия в данный момент работает.

Release cut

Таким образом, у вас никогда не возникнет ситуации, когда нажатие вашего кода на origin/feature/your-branch вызовет какие-либо проблемы для любого другого разработчика или среды перед слиянием. Это также означает, что после объединения функции в develop ваша производственная среда по-прежнему не будет содержать эту функцию, поэтому вам не о чем беспокоиться; вы можете протестировать эту функцию до того, как она попадет на рабочий сервер.

...