Базовый рабочий процесс Git для небольших проектов

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

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

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

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

1. Создайте ответвление от мастера для каждой отдельной функции или исправления ошибок.

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

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

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

2. Протестируйте ветку перед тем, как объединить ее с другим кодом.

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

3. Когда закончите с веткой, выполните интерактивную перебазировку, чтобы очистить ее.

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

4. Объединяйте ветки в мастер, не переустанавливайте его.

Если оставить ветку в истории, она выделится как функция или исправление ошибки, а фиксация слияния объясняет, что произошло в основной ветке.

Убедитесь, что сообщение о фиксации слияния является кратким, но описывающим изменения. Руководящее правило состоит в том, что нужно копаться только в коммитах ветки, чтобы понять, как они были изменены, а не что было изменено. Любой должен быть в состоянии понять весь процесс изменений и добавленных функций, просто следуя строке фиксации для Мастера.

5. Не бойтесь создавать пул-реквест, даже если он просто запрашивает ввод.

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

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

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

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

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

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

7. Используйте параметр - -rebase для предварительных вытягиваний.

По умолчанию ваши изменения объединяются с любыми предыдущими изменениями, что часто вызывает фиксацию слияния. Использование опции - -rebase, такой как «git pull - -rebase origin master», позволяет избежать этого, чтобы создать более чистую историю. Возможно, вы захотите изменить конфигурацию git, используя «git config - -global branch.autosetuprebase always», чтобы сделать это по умолчанию.

8. После того, как изменения будут объединены и отправлены вверх по потоку, не выполняйте повторное базирование без крайней необходимости.

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

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