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

Как возникла эта практика?

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

Интуитивно понятный по своей сути, коммит позволяет нам сделать моментальный снимок текущего состояния нашего кода или репозитория и сделать с ним все, что мы пожелаем, позднее (мой любимый способ — вернуть наш код на более раннюю стадию). Поскольку обучение тому, как размещать и фиксировать файлы, несложно, а перебазирование и откат не столь интуитивны, в большинстве учебных пособий не рассматриваются сложные концепции и то, как другие инструменты Git могут помочь нам при составлении наших коммитов. Коммит стал единственной вещью, о которой вы должны заботиться только при работе с Git.

Еще один важный фактор, усиливающий эту практику, связан с ошибочным представлением о том, что количество коммитов и успех проекта должны быть связаны. Количество, а не качество коммитов рассматривается многими как определяющий фактор продуктивности разработчика. Так родилась мания запросов на включение и как жалкий репозиторий мог выдавать самые плотные и впечатляющие графики на GitHub.

Если вы мне не верите, подождите, пока вы не подадите заявку на работу, и работодатель увидит вашу панель вкладов GitHub, в которой говорится, что вы сделали 50 вкладов за последний год (он только что совершил код 50 раз за год, невероятно!).

Задержка фиксирует композицию, чтобы получить контекст и скорость.

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

Что в этом плохого, спросите вы. Этот рабочий процесс оказался слишком медленным. Если бы я проработал 5 итераций по этой модели, я бы столкнулся с несколькими ямами на дороге 5 раз. Наиболее значимое из них:

  • Несвязанный код в одном промежуточном пакете.

Не знаю, как вы, но когда я кодирую, я склонен думать в терминах целого. Понятно, что это приводит к тому, что несвязанный код заканчивается одним и тем же промежуточным пакетом. Иногда я замечаю проблему и удаляю несвязанный код. Но иногда у меня есть коммиты, которые должны быть связными и сосредоточены на одной задаче, пронизанной злоумышленниками. Затем я теряю время, делая пару исправлений ради полного журнала.

  • Возможный конфликт слияния.

Если вы работаете в команде, всегда возможны конфликты слияния. После тестирования функции я обычно обновлял свой код, чтобы он отражал удаленное репо (это могло привести к конфликтам слияния по множеству причин), и после разрешения возможного конфликта я затем отправлял код. Откладывая начало этого цикла (фиксация, конфликты, тесты, CI/CD и т. д.), вы освобождаете себя для продолжения вечеринок (кодирования) и оставляете уборку дома на конец.

  • Не пользуясь более широким взглядом.

Представьте, что ваш журнал Git – это то же самое, что биография для вашей жизни. Чем дольше вы откладываете писать о себе, тем больше информации вы соберете и тем точнее будет повествование.

Первоначальный коммит должен быть опубликован как можно скорее из-за его важности при построении основной ветки.

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

Шаг 1: Код из основного репозитория, а затем выполнить ветвление

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

Шаг 2: этап на уровне патча

Когда мы инсценируем вещи, по умолчанию мы обычно инсценируем весь файл. Мы можем сделать лучше, используя флаг -p. Этот необязательный флаг позволяет нам выбирать определенные разделы файла и оставлять другие разделы нетронутыми. Преимущества многочисленны, во-первых, это освобождает разработчика для параллельного кодирования функций, а затем группировки связанного кода, когда придет время. И поскольку вы находитесь в определенной ветке, помимо подготовки, вы также можете выполнить кодирование для конкретной ветки (например, тестирование). Что бы вы ни делали на этом этапе, будьте осторожны, чтобы не переутомиться, рискуя свести на нет преимущества этой философии.

Основная цель этого шага — подготовить, зафиксировать и слить обратно в main.

Шаг 3: Используйте Rebasing, чтобы сделать линию истории более четкой

Перебазирование похоже на слияние в том смысле, что оба объединяют отдельные истории в общую линию. Слияние имеет побочные эффекты, потому что оно создает дополнительную фиксацию, а перебазирование — нет. Прочитайте эту прекрасную статью, чтобы узнать больше об их различиях.

Перебазирование имеет этот интерактивный режим, который позволяет делать всевозможные интересные вещи. Список включает в себя объединение двух коммитов в один (сквош), редактирование сообщений коммитов (edit), удаление коммитов (удаление) и т. д.

Будьте осторожны с перебазированием, особенно при работе в команде. Вы не хотите связываться с историей вашего репозитория.

Заключение

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