Содержание
Лично я уже начал переносить свои проекты в Git, потому что это очень удобно и практично (как мы видели ранее), но существуют и некоторые вещи, которых стоит избегать при работе с Git.
Распространённые ошибки программистов
Дело в том, что после каждого коммита в репозиторий его размер увеличивается (так как хранится вся история изменений файлов). На крупных проектах, над которыми работает большое количество людей этот процесс может происходить очень быстро и, зачастую, за счёт совершенно ненужных данных, итак, первая проблема:
Коммиты бинарных файлов
Покажу на практике.
Берём пример из статьи про определение серийного номера флешки с нашего сайта. Создаём новый репозиторий, прикрепляем каталог, собираем приложение и видим, что для коммита нам предлагаются сразу множество файлов – и бинарники и ресурсы и каталог _history. Всё это служебные файлы, их список может отличаться от среды к среде (разработки). Но так как мы изменяем только исходный код – остальные файлы лучше вообще исключить из рассмотрения.
Для этого в дереве проекта выберем неугодные нам файлы (все служебные, бинарные, ресурсы, xml-ы, которые мы не редактируем напрямую во время разработки) и в контекстном меню выберем пункт Ignore.
Мы значительно упростим проект, уменьшим “вес” репозитория и скорость его передачи в/из Интернет.
Боязнь создавать новые ветки
Следующая ошибка в том, что зачастую разработчики опасаются создавать новые ветки ведя работу в одной (двух?) сразу над множеством изменений.
Минусы такого подхода в том, что сложнее происходит переключение между различными этапами разработки. Кроме того затрудняется модификация проекта в части “как бы проект выглядел без этого”. Кроме того, намного эффективнее коллективная работа над различными элементами.
Конечно никто не осудит вас, если будете вести разработку в одной ветке, но намного удобнее использовать различные ответвления для различных функций и постепенное слияние в мастер-проект.
Удаление неиспользуемого кода из параллельной ветки
Ещё одна ошибка новичков в том, что выделяя новую ветвь разработки они удаляют из проекта все остальные файлы, оставляя только тот, с которым собираются работать. Так делать не нужно! Несмотря на то, что изменяться будет только один файл, при окончательном слиянии может возникнуть ситуация, когда удалённые файлы ветки удалятся также из мастер-проекта.
Если работаете только с одним файлом – незачем удалять другие. Просто игнорируйте их в этой ветке!
Редкие коммиты
Последняя в нашем списке (но не по значимости) ошибка в том, что разработчики очень редко коммитят проект. Может раз в сутки, а зачастую и после того, как изменили огромную часть кода в разных файлах.
Кроме того, коммит нужно как-то объяснять, а как можно описать коммит кода за день? “работал весь день”, ну на крайний случай можно перечислить все затронутые функции или классы. Но опять же, как тогда отлаживать процесс разработки?
В идеале после изменения определённого ключевого фрагмента и отладки работы стоит сделать коммит (моментальный снимок), чтобы всегда к нему можно было вернуться впоследствии.
Comments: