частота мерзавцев

Question

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

Я также отслеживаю некоторые другие проекты, использующие git, такие как emacs, wordpress и т. Д. Я вижу, что они не так часто фиксируют. Так что мне интересно, как часто вы делаете это?

Answer 1

Руководство для самого проекта Git (и проекта Linux, AFAIK) - это один коммит на «логически отдельный набор изменений».

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

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

Answer 2

Я также отслеживаю некоторые другие проекты, использующие git, такие как emacs, wordpress и т. Д. Я вижу, что они не так часто фиксируются.

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

Answer 3

В конце концов я заканчиваю фиксацию функции функцией

Не забывайте, что вы можете вместо функции "git add" выполнять только один коммит:

• как только все функции написаны или исправлены для данной задачи
• или как только вы поймете, что текущая функция слишком велика / сложна, чтобы в ближайшее время стать частью коммита: вы можете зафиксировать то, что в данный момент находится «на стадии» («добавлен git»), которое не будет включать ваши текущие изменения в рабочем каталоге.

Тогда количество коммитов может быть связано с назначением ветки:

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

Короче говоря, « публикация соображения» может в D VCS (как в «Распределенном») помочь вам сделать правильное количество коммитов по правильным причинам. .

Answer 4

Чем больше вы совершаете, тем легче находить ошибки с git bisect

Answer 5

Как только тесты пройдены или когда единица функциональности добавлена ​​/ удалена / изменена.

Answer 6

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

Answer 7

Это действительно зависит.

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

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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

4- Описания коммитов необязательны, но их приятно иметь.