git-practices-to-boost

Git это широко используемая распределенная система контроля версий. И опыт использования гита играет огромную роль в повышении качества кода вашей команды и общей продуктивности.

В этом посте я поделюсь 10 советами по работе с git, используя которые вы повысите свою продуктивности до 80% всего за неделю.

Эти 10 правил так же известны как DIG AFTER RUGBY

№1. Не Игнорируйте GitIgnore

Это правило поможет содержать ваш код в чистоте. Используйте его и тогда каждый ваш коммит, пуш и пулл реквест будет чистым и красивым, если используется правильный gitignore файл.

Вы можете использовать как локальный .gitignore, так и глобальный

№2. Атомарные Коммиты

Атомарный коммит, это коммит который сфокусирован на одной задачке и только на ней. Идея в том, что вам необходимо разбивать вашу задачу на маленькие подзадачки и решать их по отдельности.

Это правило поможет вам оставаться сконцентрированным на одной задаче. Так же атомарные коммиты будут полезны для других разработчиков. Они смогут лучше разобраться в вашем проекте благодаря таким коммитам.

№3 Частые Коммиты

Позвольте сначала задать вам вопрос.
Вы когда-нибудь видели правило –
Можно ли коммитить больше 2 раз за час?
Или Можно ли коммитить больше 10 раз за день?

Конечно нет, ведь такого правила нет. Никто не запрещает вам делать частые коммиты. Вы можете коммитить каждый раз, когда вы готовы. Это поможет и вам, и вашей команде избегать множество конфликтов в коде.

№4 Тестируйте Перед Пушем

Тестирование перед пушем это крайне важное правило. Когда вы коммитите свои изменения, вы обновляете локальный репозиторий. А когда делаете пулл реквест вы пытаетесь обновить удаленный репозиторий.

И если ваш коммит сломал код, то это ни на кого не повлияет кроме вас. Однако если вы обновите удаленный репозиторий со сломанным кодом, ваша команда не сможет продолжить работать.

Обычные 5 минут тестирования кода могут спасти часы командной продуктивности

№5 Обеспечивайте Соблюдение Стандартов

Если вы работаете в команде, то возможно что вы или ваш коллега можете забывать использовать стандарты кода.

Как это исправить? – Заставлять соблюдать стандарты.

Один из важный стандартов – На каждом коммите должно быть сообщение. Изначально вы можете коммитить изменениябез сообщения коммита. Но если вы или кто-то коммитит без сообщения, поможет ли это кому-то? Нет.

Вам следует обеспечивать соблюдение стандартов и на каждом коммите должно быть сообщение. И этого можно достичь используя Git hooks.

№6 Исправление это Не Тоже Самое Что и Добавление Новых Фич

Многие разработчики исправляют свой код как будто делают улучшения. Это нормально. Но некоторый смешивают исправление с добавлением новых фич.

Не следует перемешивать рефакторинг и добавление нового функционала. У этого есть 2 недостатка
– Это увеличивает шанс возникновения конфликта
– Ваш код сложнее Ревьюить

Но если рефакторинг необходим, делайте сначала его.

№7 Перезаписывание Истории Непозволительно в Публичных Ветках

Вам не следует перезаписывать историю общих веток.

Если вы сделали опечатку в недавнем коммите, можно использовать опцию amend. В общем, следует держать гит историю в чистоте. Это поможет найти последний рабочий коммит и вернуться к предыдущим коммитом без разворачивания полезных изменений.

№8 Используйте Пулл Реквесты

Пулл Реквесты полезны, так как помогают держать мастер чистым, надежным и готовым к работе. Все коммиты в мастер должны проходить пулл реквест.

Вот 3 основных преимущества использования пулл реквестов
  • Ревью Кода – код ревью помогает поддерживать единый стандарт кода в проекте и помогает вашей команде лучше знать кодовую базу.
  • Лучшая Стабильность – Каждый раз когда вы пушите ветку ваш CI прогоняет на ней все тесты
  • Continuous Delivery – Так как ваш мастер всегда в рабочем состоянии это способствует continuous delivery

№9 Ветки Должны Быть Актуальными

Держите ваши ветки в актуальном состоянии. Это полезно если у вас самостоятельная ветка

Это правило поможет вам и команде сохранить время. С одной стороны, вам придется тратить время на разрешение конфликтов слияния

Но с другой стороны, если вы поддерживаете актуальность веток, то будет очень просто работать с любой веткой и быть актуальным при любой работе.

№10 Вы Должны Быть Принять Ответственность За Свой Код

В конце концов, вся agile команда отвечает за репозиторий. Поэтому мы все берем на себя ответственность за нашу работу.

Запомните – Когда вы работаете в спринте, успех спринта это успех каждого отдельного участника спринта. И если вы провалили спринт, каждый участник ответственен за это.

Exit mobile version