Как по-настоящему использовать Git: 10 правил, которые сделают Git более полезным

Контроль версий может быть невероятно полезным инструментом: он обеспечивает защиту от ошибок, позволяет понять, как развивался ваш проект, и, в конечном счете, дает вам возможность вывести качество процесса разработки программного обеспечения на совершенно новый уровень.

Но только если вы знаете, как эффективно использовать систему контроля версий и Git. Вот 10 правил, которые могут вам помочь!

1. Фиксация связанных изменений

Коммит должен быть контейнером для связанных изменений. «Связанные» в этом контексте означает, что в один и тот же коммит должны быть включены только изменения, относящиеся к одной и той же теме. Почему? Потому что гораздо легче понять коммит, если он касается только одной темы, а не множества разных вещей.

В качестве приятного побочного эффекта это также производит меньшие коммиты. Это облегчает другим разработчикам понимание изменений (и их откат, если что-то пошло не так). Чтобы сделать простой практический пример: исправление двух разных ошибок должно происходить в двух отдельных коммитах!

К счастью, Git предлагает полезные инструменты, которые позволяют нам работать таким точным образом:

1. Staging Area, которая позволяет вам решить, какие именно части или даже строки вы хотите в следующем коммите.

1. Тайник, который поможет вам сохранить изменения, которые вам не нужны в данный момент, во временном буфере обмена.

2. Часто совершайте коммиты

Почему вы должны делать коммиты часто? В основном по двум причинам:

1. Меньшие коммиты: Вы получите меньшие коммиты по сравнению с редкими коммитами, когда накопилось много-много изменений. Еще раз: небольшие коммиты легче понять вашим товарищам по команде (и вам самим, через некоторое время).

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

3. Никогда не беритесь за работу наполовину

Код должен быть зафиксирован только после того, как он действительно завершен. Это НЕ означает, что вы должны завершить целую большую функцию, прежде чем совершить коммит. Наоборот, вам следует разделить реализацию на логические части и делать коммиты как можно раньше и чаще. Но вы не должны совершать коммиты только для того, чтобы у вас было что-то в репозитории Git, прежде чем покинуть офис в конце долгого дня.

Другая ситуация, которая соблазняет нас зафиксировать наполовину сделанную работу, — это когда нам нужна чистая рабочая копия (например, когда нам нужно проверить другую ветку, вытащить или слить...). Но вместо фиксации такую ​​ситуацию можно легко решить, сохранив локальные изменения в Git «Stash».

4. Тестируйте перед фиксацией

Тесно связано с правилом № 3 следующее: мы должны сопротивляться искушению совершить что-то, что мы «думаем» завершенным. Многие команды публично определяют свое «определение готовности», включающее тесты. Но даже если он не приклеен к стенам вашего офиса, все равно стоит тщательно протестировать код перед его фиксацией. Это поможет вам убедиться, что он действительно полный и не имеет побочных эффектов.

Ваши товарищи по команде оценят каждую минуту, которую вы потратили на тестирование своего кода. Потому что это уменьшает те очень разочаровывающие ситуации, когда вы получаете изменения от своих коллег только для того, чтобы обнаружить, что код больше не работает ☹️🤯

5. Пишите описательные сообщения фиксации

Помимо фактического кода, сообщение коммита — единственная часть информации, которая помогает людям понять, что произошло. Это делает сообщения о коммитах очень важной темой!

Вы должны начать свое сообщение с краткого описания ваших изменений (примерно до 50 символов). Это помогает отделить это небольшое резюме от следующего текста, включив пустую строку: если вы сделаете это, большинство инструментов поймут, что эта первая строка является «темой», а остальная часть — «телом» сообщения (аналогично электронное письмо).

В теле сообщения должны быть подробные ответы на следующие вопросы:

• Что послужило мотивом для этого изменения?

• Какие аспекты предыдущей реализации он меняет?

Чтобы соответствовать автоматически генерируемым сообщениям от таких команд, как «git merge», вы можете использовать повелительное наклонение в настоящем времени («изменить», а не «изменить» или «изменить»).

6. Не путайте контроль версий с системой резервного копирования

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

Если бы Git был в основном системой резервного копирования, вы могли бы просто впихивать свои файлы и изменения всякий раз, когда и как бы они ни появлялись.

Но контроль версий, напротив, заключается в придании вашим коммитам семантической ценности! Речь идет о создании детализированных, точных коммитов, которые относятся только к одной теме для каждого коммита.

7. Активно используйте ветки

Когда Git проектировался, основным требованием было сделать концепцию «веток» быстрой, простой и надежной. Если вы пришли из других систем управления версиями, вы знаете, что понимание веток в большинстве других систем не соответствует этому описанию! В большинстве других СКВ ветвление либо медленное, либо сложное, либо его вообще нет!

Однако в Git ветвление является одной из самых важных функций — и это не преувеличение! Ветки в Git — идеальный инструмент, который поможет вам не смешивать разные направления разработки. В любое время, когда вам это нужно, они предоставят вам отдельный контейнер для вашей новой работы. Это позволяет невероятно легко и безопасно экспериментировать с новым кодом и функциями, не рискуя заблокировать команду из-за ошибок, которые неизбежно содержатся в новом коде.

Широко используйте ветки в своих рабочих процессах разработки: для новых функций, исправлений ошибок, идей…

8. Согласуйте рабочий процесс в вашей команде

Git не принуждает вас к какому-либо конкретному рабочему процессу. Вы можете использовать одну или несколько долгосрочных веток, тематических веток для работы над функциями, слияние вместо перебазирования, использование git-flow… но это не обязательно! Какие ингредиенты вы выберете, зависит от многих факторов: вашего проекта, ваших общих рабочих процессов разработки и развертывания и (что наиболее важно) личных предпочтений вашей команды.

Но, тем не менее, вы решаете работать в конце концов: убедитесь, что где-то задокументировали этот рабочий процесс и возложите ответственность за его выполнение на всех в команде!

9. Узнайте больше, чем основы

Вы наверняка сможете «выжить», зная всего несколько команд Git. Но вы упустите столько возможностей Git, если не узнаете о расширенных функциях! Сделать всего три примера:

• Reflog может помочь вам найти потерянные коммиты. Это может быть чрезвычайно полезно, когда вы только что «удалили» некоторые коммиты, которых у вас быть не должно!

• Interactive Rebase может помочь вам очистить историю коммитов, прежде чем вы поделитесь ею со своей командой. Это делает кодовую базу намного чище и проще для понимания в долгосрочной перспективе!

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

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

10. Выберите инструменты, которые сделают вас более продуктивными

Сегодня экосистема вокруг Git полна мощных инструментов и сервисов: от сервисов хостинга кода, таких как GitHub, Gitlab и Bitbucket вплоть до Git Desktop GUI, например Tower.

Тщательно выбирайте инструменты, потому что они могут помочь вам повысить продуктивность работы с Git и упростить доступ к его расширенным функциям.

Об авторе

Бруно Брито — разработчик контент-маркетинга Tower, популярный клиент Git для настольных ПК, который помогает более 100 000 разработчиков по всему миру работать с Git более продуктивно.