При использовании git для управления кодом стратегия управления ветвями должна быть стандартизирована и унифицирована между разработчиками. Существующие общие стратегии управления ветками включают TBD, поток Github и поток git. Что касается вышеперечисленных стратегий, в этой статье они не повторяются, и заинтересованные студенты могут обратиться к этой статье. Лучшие практики управления ветками Git
TBD в сторону. Поскольку в потоке Github нет единой ветки разработки, есть только разные ветки функций.Когда несколько человек разрабатывают несколько требований, ветка функций и функция могут легко перекрыть друг друга при выпуске тестового сервера. С другой стороны, git-flow связан с тем, что ветки функций объединяются в ветку разработки, а требования к следующей версии объединяются в ветку разработки и выпускаются вместе.Временный запуск функции по отдельности может вызвать проблемы. Он подходит для групп разработчиков с длительными циклами итерации версий и четкими требованиями к версиям. Однако он может не подходить для таких ситуаций, как наша команда, где цикл спроса короткий, содержание разработки изменчиво, а несколько человек параллельно разрабатывают несколько требований. Поэтому мы внесли некоторые изменения в поток Github, чтобы сформулировать и стандартизировать более гибкую стратегию управления ветками.
Всего три отделения. Как и поток Github, роль основной ветки заключается в обеспечении стабильной и надежной базы кода. Ни одному разработчику не разрешено коммитить непроверенный или непроверенный код непосредственно в основную ветку. Ветка разработки используется для слияния разрабатываемых функций для тестирования. Когда появляется новая фича или обнаруживается новая ошибка, мы все вырезаем ветку из мастера, а после изменения кода сливаем ветку в разработку для тестирования. Если тест не пройден, вернитесь к ветке функций или ошибок для модификации до тех пор, пока тест не пройдет, и объедините ветку функций с основной веткой через запрос на слияние для выпуска. Это позволяет избежать проблемы, связанной с тем, что разные выпуски веток функций в Github Flow перекрывают друг друга, а также позволяет избежать проблемы, связанной с тем, что функция git-flow не может быть временно выпущена независимо.
Конечно, описанная выше стратегия ветвления также имеет проблемы, такие как частое переключение ветвей. Было бы намного проще иметь плагин, такой как git-flow.
Стратегия управления филиалом зависит от мнения, нет абсолютно лучшего, есть только то, что наиболее подходит для вашей команды. выше.