Это действительно важный вопрос, так как многие люди фактически пренебрегают своим списком коммитов. Они не должны этого делать, потому что хорошо организованный репозиторий радикально повышает ценность проекта, достигая точки, когда предоставляемая информация, когда ее легко получить, является почти более ценной, чем сам код.
Короче говоря:
- позаботьтесь о описаниях коммитов и расскажите, что на самом деле делают изменения, а не то, что вы сделали за определенный промежуток времени;
- Постарайтесь сохранить историю вашего репозитория такой же чистой, как и ваш код.
Лично я полностью принял рекомендации по разработке ядра Linux для своих собственных проектов. Это те, которые соблазнили меня больше всего.
В основном он состоит из группировки изменений в « логических единицах », которые могут привести вас либо к массовым коммитам, либо к одиночным.
Например, исходные коды ядра поставляются с инструментом под названием sparse , который сканирует все файлы C и проверяет возможные семантические проблемы. Этот инструмент периодически обновляется, когда обнаруживается что-то новое, и мы хотим очистить весь проект. Среди вещей, которые нужно было изменить, было удаление почтового адреса FSF, который используется для включения в лицензию в виде текстового комментария вверху каждого исходного файла.
В этом конкретном случае я бы собрал все эти наборы изменений (урезав верхний комментарий) в один выделенный для этого коммит, а именно: содержащий удаление этого раздела для каждого файла C (даже если в каталог подсистемы) но больше ничего. Никаких дополнительных изменений кода или побочных модификаций. Затем я подготовил бы другие коммиты для остальной части моей работы.
Это уже требовалось до Git, так как большинство этих изменений до сих пор (и фактически остаются) представлены в виде «исправлений» сопровождающему, отвечающему за их проверку, прежде чем он решит интегрировать их или нет. Вы можете не только отправить ему большой тарбол с работой недели с уведомлением «справиться с этим самостоятельно», но и получить готовые исправления, а люди могут при желании отклонить некоторые из ваших запросов. исправления, в то же время принимая большинство остальных, затем позволяя вам исправить те, которые вызывают проблемы, и отправлять их снова.
Кроме того, обычной практикой в многопользовательском проекте разработки является никогда не переписывать «историю»… если только все главные герои не будут идеально использованы с Git и не справятся с этим. Однако ничто не мешает вам изменить свою историю перед публикацией. Итак, что вы можете сделать при разработке, если у вас нет времени сосредоточиться на «упаковке», это зафиксировать все в личной временной ветке, пока вы не закончите, а затем выбрать все материалы по темам на В официальной ветке разработки проверьте с помощью git diff, синхронизированы ли вершины вашей временной ветки и ветки разработки, и, наконец, продвиньте свою работу.
Еще одна веская причина заботиться о коммитах - воспользоваться командами расследования, такими как git blame. Если, например, вы попали в строку, которая использовалась для управления личностью пользователя и внезапно перестала работать, вам не только понравится git blame, чтобы указать точную фиксацию, которая привела к изменению, но также и быстро получить весь контекст , с небольшим количеством информации. В данном конкретном случае это может быть связано с тем, что все проверки идентичности были централизованы в восходящем направлении в выделенной функции или модуле.
Это потому, что Git в основном ориентирован таким образом, что определенные команды, такие как git add, предназначены для индивидуального выбора файла по умолчанию и требуют некоторых параметров (таких как -u или -A ), чтобы выбрать все, что было изменено (в отличие от некоторых других SCM, таких как Mercurial, который предоставляет addremove, что оказалось ложной хорошей идеей).
Чтобы помочь вам в этом, вы, конечно, можете включать файлы по одному. Но вы также захотите проверить:
git add -p
… для индивидуального выбора фрагментов из одного измененного файла. Затем вы можете использовать
git diff
git diff --cached
… чтобы проверить, что еще нужно добавить и что вы уже подготовили для следующего коммита.
Наконец, обязательно заботьтесь о теле сообщения в каждом коммите, потому что именно здесь должна быть записана причина чего-либо. Большое количество разработчиков просто указывают что-то внутри строки темы с помощью git commit -m, но описание фиксации позволяет избежать установки этой информации непосредственно в коде, сохраняя ее в чистоте.