Должен ли каждый git commit оставлять проект в рабочем состоянии?

Мне любопытно узнать, какова преобладающая лучшая практика. Следует ли применять git-коммиты таким образом, чтобы проект находился в рабочем состоянии (сборка выполнялась правильно, все тесты прошли и т. Д.), Или исправление испорченного кода в порядке?

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

Я обычно следую этому правилу:

• Каждое слияние с masterветкой должно оставлять проект в рабочем состоянии;
• Каждое слияние с основной developветкой должно оставлять проект в рабочем состоянии (и он должен быть построен как минимум);
• Каждая отдельная фиксация имеет первостепенную цель объяснить, почему было внесено изменение, для чего оно предназначено и на какие части проекта оно повлияло. Все остальные цели, такие как перевод проекта в рабочее состояние, являются необязательными.

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

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

git rebase -i HEAD~4

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

Затем я могу выполнить этот атомарный коммит, или, на самом деле, то, что я делаю, если моя новая функция действительно готова, - это использовать «git cvsexportcommit», чтобы перенести мою работу в существующее хранилище CVS.

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

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

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

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

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

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

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

Мы используем git flow на работе, и мы также фиксируем незаконченный или неработающий код - так как он попадает только в локальные или удаленные ветви, созданные для этой конкретной проблемы. Только после того, как задача завершена, она объединяется с ветвью разработки (которая представляет текущую рабочую копию в модели потока). Таким образом, мы также можем совместно работать над кодом (некоторые сотрудники находятся в другом городе, включая руководителя проекта) и помогать друг другу.

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

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

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

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

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

Предполагая, что вы используете ветки и хорошие сообщения о коммите, фиксация «испорченного» кода в ветке с сообщением о коммите, которое проясняет это, будет хорошо, если ваша команда согласится, что это хорошая рабочая практика.

Вы также клонируете репозиторий git локально, так что у вас вполне может быть локальная ветка с локальными коммитами, не выдвинутыми в исходную точку, где вы делаете «сломанный» код по ходу работы; затем, когда у вас все это работает, вы можете объединить его с master или какой-либо другой веткой и удалить вашу рабочую ветку с различными «нарушенными» коммитами.

Для меня это все о согласии с вашей командой, что является приемлемым; некоторые команды не примут неработающий код даже на ветке, другие примут.