" вы не должны публиковать изменения на пульте дистанционного управления до тех пор, пока вы не перезагрузите "
Я полностью не согласен с этим утверждением; ничто из того, что вы описываете, не должно требовать перебазирования.
Проблема, которую вы описываете, заставляет это звучать так, как будто у вас only есть ветвь master на вашем пульте, и что вы разветвляли ветки функций от этого. Это идет против Git Flow .
Не беспокойтесь о длительных ветвях функций - это совершенно нормально, и вы прекрасно можете многократно выдвигать такую ветвь до origin. Это даже рекомендуется из-за резервного копирования в Git (который вы упомянули).
Вы хотите следовать типичному Git Flow:
- У вас есть
master ветвь, подключенная к вашей производственной среде,
- Вы отделяете
develop от своей master ветви
(и подключаете это к средам разработки и тестирования).
- Вы ветвите каждое из ваших
feature ответвлений от develop, а не master,
- В любое время, независимо от того, завершена функция или нет, вы делаете коммит на
origin/feature/your-branch,
- Когда эта функция будет завершена, вы объединяетесь с
develop посредством запроса на извлечение.
ЭТО - единственное место, где могут возникнуть конфликты!
- Если есть конфликты, вы исправляете их в своей локальной ветви,
pull вставляя ветку develop в свою локальную ветку функций. Вам может понадобиться stash ваши изменения в первую очередь. Затем вы можете push свой локальный филиал вернуться к origin - ветвь функции еще не будет объединена.
- После разрешения конфликтов ветвь объединяется в
develop.
develop затем развертывается в вашей среде разработки (предпочтительно автоматически через инструмент непрерывной интеграции, такой как Jenkins или TeamCity). Таким образом, среда разработки всегда имеет все новейшие функции.
- После того, как вы тщательно протестировали свои функции, вы создаете сокращение выпуска функций и выпускаете эту версию до
master (которая развернута в рабочей среде). На этом этапе также полезно добавить tag в ветку, чтобы вы точно знали, какая версия в данный момент работает.
Таким образом, у вас никогда не возникнет ситуации, когда нажатие вашего кода на origin/feature/your-branch вызовет какие-либо проблемы для любого другого разработчика или среды перед слиянием. Это также означает, что после объединения функции в develop ваша производственная среда по-прежнему не будет содержать эту функцию, поэтому вам не о чем беспокоиться; вы можете протестировать эту функцию до того, как она попадет на рабочий сервер.