Помните, что о каждом бессистемном git-репозитории в мире грустит один щеночек. Вы ведь не хотите расстраивать еще одного?
Бросим все силы на борьбу с собачьей грустью!
Все приведенные в статье советы могут быть использованы как в краткосрочных, так и в долговременных проектах. Они сочетают в себе лучшие практики, а также личный опыт профессиональных разработчиков.
Совет 1. Комментируйте коммиты с умом
Пишите к вашим коммитам короткие и осмысленные сообщения. В идеале они должны быть связаны с тикетами в вашей системе управления проектами. Это позволит легко найти соответствующую задачу и всю необходимую информацию по коммиту.
Например, если вы используете JIRA, начинайте каждый комментарий с префикса JIRA-тикетов. Так вы сможете перейти к задаче простым кликом и получить список всех относящихся к ней коммитов.
Совет 2. Gitflow: действуйте по плану
Если вы незнакомы с Gitflow, то обязательно загляните в руководство Atlassian или наш материал.
Это очень полезная штука, которая помогает придерживаться плана и держать проект в чистоте и порядке независимо от его размера. Использование единого соглашения облегчает работу в команде.
Когда проект поддерживает множество разработчиков, становится трудно отслеживать, где, когда и почему была развернута какая-то ветка. В продакшн может попасть то, что не должно там быть, особенно после мелких правок. Gitflow устанавливает четкие правила работы в git-репозитории проекта и позволяет избежать таких ошибок.
Совет 3. Создавайте пулл-запросы
Pull request, или запрос на слияние, – это простой способ сообщить вашим товарищам по команде, что функциональность, над которой вы работали, готова. Gitlab дает возможность уведомить об этом заинтересованных лиц.
Главная идея таких запросов – создать точку в git-репозитории, в которой можно обсудить конечный вариант новой фичи.
Есть еще один большой плюс. Когда ваш код мержит кто-то другой, знания и ответственность в отношении конкретной функции разделяются.
Совет 4. Поддерживайте чистоту в git-репозитории
Чтобы ваша история коммитов не стала похожа на этот скриншот, используйте возможности git. Разберем две особенно полезные команды: git commit --amend и git rebase.
Git commit --amend
Это простой способ изменить последний коммит. Вместо того, чтобы фиксировать новые изменения отдельно, вы просто объединяете их с предыдущими.
Git rebase
Rebasing (перебазирование или перемещение) позволяет сохранить в вашей feature-ветке ту же историю коммитов, что и в master. Это предотвратит опережение других веток и спасет от ужасных конфликтов слияния.
Внимание!
Обе эти команды переписывают историю в git-репозитории и могут стать причиной больших проблем при командной работе. Перемещенная ветка не "перематывается" (fast forward) при отправке в удаленный репозиторий, поскольку между существующими коммитами вставлены новые. Необходимо выполнить git push --force, чтобы перезаписать состояние удаленной ветки.
Если кто-то запушил коммиты, которых нет в вашем локальном git-репозитории, то вы можете затереть их. Чтобы уменьшить риск потери изменений, следует вместо флага --force использовать --force-with-lease. При этом возникнет ошибка, если удаленная ветка уже была кем-то изменена, и чужие коммиты не будут перезаписаны.
Избегайте push --force по мере возможности, но если он вам все-таки потребовался, предупредите остальных членов команды.
Совет 5. Версионируйте проект
Семантическое управление версиями – отличная практика, которая позволит навести порядок в вашем git-репозитории.
Выглядит это так: v Major.Minor.Patch, например, v3.5.2.
- Major – крупное изменение приложения, обычно эта цифра меняется реже остальных;
- Minor – небольшое обновление, которое может включать также общее обслуживание проекта и незначительные изменения;
- Patch – исправление. Это число изменяется только в том случае, если в проекте нашелся какой-то баг и вы его исправили.
Вот пример версионированного проекта. В версии 3.3 появилась новая функция Test module. После минорного выпуска было 4 патча: обновления безопасности и конфиденциальности, а также фиксы багов.
Советы для PRO
Именование файлов (core.ignorecase)
По какой-то причине Mac OS по умолчанию не учитывает регистр в файловой системе. Это вызывает много проблем.
Например, в вашем проекте есть два файла: HelloController.php и helloController.php. На Mac OS все работает отлично, вы делаете коммит и отправляете изменения в репозиторий. Но на другой операционной системе появится сообщение об ошибке вида "HelloController.php not found".
Вы можете переименовать файл, но git этого не увидит, ведь по умолчанию он игнорирует регистр.
Эту опцию можно глобально отключить с помощью команды:
git config --global core.ignorecase false
Файловый режим (core.fileMode)
Хотя по умолчанию git игнорирует регистр, он отслеживает режимы файлов. Если вы изменили права доступа к файлам, не изменив в них ни строчки, git все же покажет изменения.
Эту опцию можно отключить глобально, выполнив следующую команду:
git config --global core.fileMode false
Grumphp
Grumphp – это инструмент, который пропускает все изменения кода через набор тестов и проверяет, соответствуют ли они настроенным требованиям.
Щеночек счастлив!
Ура, вы спасли щеночка и сохранили чистоту и уют в вашем git-репозитории. Если у вас есть собственные приемы поддержания порядка, поделитесь ими в комментариях.
Перевод статьи How to save a puppy by creating a clean Git repo.
Комментарии