5 идей для улучшенного рабочего процесса GitHub
В зависимости от вашей истории работы с системой контроля версий способ, которым вы работаете с кодовой базой, делаете коммиты и т. д., различается.
Кроме того, в зависимости от того, используете ли вы Git, Subversion, Mercurial и т. д., вы также определяете, как вы управляете своим кодом.
Но если вы тот, кто работает с Git (я знаю, что многие люди в WordPress начинают использовать все больше и больше почти ежедневно), есть несколько небольших вещей, которые я рекомендую сделать, чтобы помочь управлять изменениями, особенно с командой более управляемым.
Советы по расширенному рабочему процессу GitHub
1 Не соглашайтесь на роль мастера
Master следует использовать специально для кода, готового к производству и развертыванию. Это не ваша рабочая ветка, это не ваша рабочая ветка.
Вообще говоря, здесь объединяются все пулл-реквесты.
2 Старайтесь всегда создавать ветки
Всякий раз, когда у вас есть набор задач, проблем или вех, создайте ветку и убедитесь, что все, над чем вы работаете, связано. Например, вы не хотите выполнять работу с базой данных и работу с JavaScript в своих запросах на вытягивание.
3 Группируйте свою работу
Даже если вы работаете исключительно над фронтендом, вам может понадобиться разбить его на более мелкие ветки. Это упрощает проверку кода и улучшает запросы на извлечение.
4 Создавайте небольшие PR
Это очень похоже на предыдущий заголовок, но идея создания небольших PR гораздо более продуктивна, чем создание более длинных запросов на вытягивание.
- Это помогает, когда вам нужно запросить проверку кода, так как это дает вашим товарищам по команде более простой способ обрабатывать проверки кода и предлагать отзывы.
- Это делает журнал изменений компактным и помогает предоставить подробный отчет о том, что делает конкретный пакет кода.
Но что представляет собой хороший PR?
5 Расскажите хорошие детали в своем PR
Насколько я понимаю, хороший запрос на включение сделает небольшой набор вещей:
- В одном-двух предложениях подробно опишите, чего должен ожидать человек, просматривающий ваши изменения.
- Привяжите PR к заявке, карточке управления проектом (или как там это называется в вашей системе),
- Перечислите более короткие версии сообщений фиксации, чтобы сделать их максимально удобными для вашего рецензента.
Тем не менее, вы, вероятно, можете сделать еще много вещей, но это те вещи, которые я нашел наиболее полезными (и я должен сказать, что некоторые из этих вещей я не узнал от моей команды ).
Есть ли еще вещи?
Всегда.
Но это несколько вещей, которые я нахожу все более и более полезными, особенно при отслеживании изменений, работе с другими и работе с запросами на вытягивание (как от тех, с кем я работаю, так и от тех, кто участвует в проектах с открытым исходным кодом).
Наконец, ни одна из этих вещей не является предписывающей. Существует кривая обучения (говоря по опыту), но я рекомендую попробовать некоторые из них хотя бы по той причине, что посмотреть, не улучшит ли это ваш рабочий процесс.
Даже если это совсем немного.