Пару лет назад в университете я помню, как написал краткое изложение на одной странице о лучших практиках git, которые мы должны применять в программировании.
Сейчас, оглядываясь назад, я чувствую, что тогда не осознавал до конца, насколько важны были эти практики.
Конечно, некоторые из них более важны, чем другие, но они по сей день остаются для меня хорошими ориентирами в моей повседневной работе инженера-программиста.
Лучшие практики: стиль кодирования
Перед фиксацией: проверьте стиль кодирования
- Схема именования, например. переменные, классы, методы
- Интервал, стиль комментария, предпочтительные библиотеки, особенности языка
- Используйте проверку стиля, если это возможно/настройте свою IDE
- Языковой стиль.
Используйте стиль кодирования проекта
- Стиль проекта имеет приоритет
- Патч следует стилю кодирования
- Облегчает чтение кода для других разработчиков
- Предотвращает ошибки, вызванные удобочитаемостью
Передовой опыт: коммиты:
Одно логические изменения
- Потому что несколько изменений, зафиксированных вместе, нельзя отменить/повторить по отдельности.
- Изменения могут быть лучше приняты (выбранные вишни)
- Легче просматривать и находить ошибки
Не нарушайте сборку
- Фиксируйте только те изменения, которые сохраняют целостность системы
- Никаких «критических изменений»: никаких ошибок компилятора при фиксации
- Избегайте коммитов, которые исправляют другие коммиты, например. «Добавить изменения, отсутствующие в предыдущем коммите», вместо этого переработать историю.
- Держите некритическую очистку/переформатирование отдельно от функциональных изменений: это можно отменить в случае конфликта слияния.
Избегайте регрессий
- Запускайте модульные тесты перед фиксацией
- Поддерживайте актуальность набора тестов
- Расскажите о ручных тестах
Передовой опыт: разделение работы
Общайтесь с другими разработчиками
- Избегайте конфликтов слияния, по возможности не работая над одними и теми же областями.
- Обсуждаем и согласовываем дизайн
- Следуйте инструкциям и спецификациям проекта
- Регулярные проверки и мероприятия по очистке
Исправить очаги конфликтов
- Файлы, вызывающие частые конфликты
- Конфликты указывают на важные недостатки/проблемы дизайна
- Сильная связь между модулями.
Объединить фиксацию
- Слияние должно содержать только изменения из трехстороннего слияния:
- Если требуется ручное слияние, следует применять дисциплину программирования.
- Должен содержать только изменения, устраняющие конфликты
Репозиторий для исходного кода
Зафиксировать только исходные файлы, а не сгенерированные файлы
- Избегайте проверки сторонних библиотек, например. Мавен зависимости.
Включить файлы сборки:
- Независимые от платформы инструкции по сборке
- Исключите определенные файлы IDE или локальные конфигурации.
- Важно, потому что: файлы остаются в истории и должны быть загружены всеми
Как написать хороший коммит!
Объясните, что изменилось и почему это изменилось
Семь золотых правил:
- отделить тему от тела пустой строкой
- Ограничьте строку темы до 50 символов.
- Используйте заглавные буквы в строке темы
- Не заканчивайте строку темы точкой
- Используйте повелительное наклонение в строке темы (если это применяется, фиксация будет [ваша тема])
- Оберните текст 72 символа.
- Используйте тело, чтобы объяснить что и почему, а не как.
