Pull request. Как правильно организовать?
#разработка #вопрос #комментарии
Во всех компаниях, которые так или иначе связаны с разработкой, используется система контроля версий. И одна из самых распространенных является Git.
Для того, чтобы обеспечить надлежащее качество кода, используется pull request. По своей сути, это возможность другим участникам репозитория посмотреть изменения в коде, увидеть потенциальные или явные проблемы в нем и сообщить об этом тому, кто этот код писал.
Этот процесс позволяет другим участникам проекта ознакамливаться с новым кодом, предотвращать потенциальные баги и держать кодовую базу в общем ключе. Единственным минусом являются временные затраты.
Мы всем используем эту технику, но насколько правильно? Например, в нашей команде существует ряд правил, которые связаны с PR:
1) Объем каждого PR не должен превышать 500 строк кода. Если же фича занимает больший объем, то ее надо разбить на несколько PR, помечая, что текущая ветка должна вливаться не в dev, а в родительскую.
2) Каждый PR должен сопровождаться кратким описанием того, что в нем было сделано.
3) Добавление ресурсов и переименование желательно выносить в отдельный PR.
4) Те pull request, которые надо влить в общую ветку должны быть проверены при помощи тестов, развернутых на CI.
Эти правила помогают нам лучше организовывать работу в команде, связанную с созданием PR.
А какие есть правила у вас в команде, связанные с PR?
Очень интересно узнать и взять на заметку что-то новое для себя. Прошу поделиться в комментариях.
#разработка #вопрос #комментарии
Во всех компаниях, которые так или иначе связаны с разработкой, используется система контроля версий. И одна из самых распространенных является Git.
Для того, чтобы обеспечить надлежащее качество кода, используется pull request. По своей сути, это возможность другим участникам репозитория посмотреть изменения в коде, увидеть потенциальные или явные проблемы в нем и сообщить об этом тому, кто этот код писал.
Этот процесс позволяет другим участникам проекта ознакамливаться с новым кодом, предотвращать потенциальные баги и держать кодовую базу в общем ключе. Единственным минусом являются временные затраты.
Мы всем используем эту технику, но насколько правильно? Например, в нашей команде существует ряд правил, которые связаны с PR:
1) Объем каждого PR не должен превышать 500 строк кода. Если же фича занимает больший объем, то ее надо разбить на несколько PR, помечая, что текущая ветка должна вливаться не в dev, а в родительскую.
2) Каждый PR должен сопровождаться кратким описанием того, что в нем было сделано.
3) Добавление ресурсов и переименование желательно выносить в отдельный PR.
4) Те pull request, которые надо влить в общую ветку должны быть проверены при помощи тестов, развернутых на CI.
Эти правила помогают нам лучше организовывать работу в команде, связанную с созданием PR.
А какие есть правила у вас в команде, связанные с PR?
Очень интересно узнать и взять на заметку что-то новое для себя. Прошу поделиться в комментариях.