Git стиль фиксации: все измененные файлы одновременно или по одному за раз?

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

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

Мне интересно, что делают остальные, которые используют git. Кроме того, если бы вы могли прочесть это для меня. Я новичок в git, и я использую TortoiseGit и gitk в Windows.

ОТВЕТЫ

Ответ 1

Когда совершать и что совершать - это искусство, и нет черно-белых правил. Это, как говорится, есть привычки, которые легче понять, чем другие.

В целом, я думаю, вы должны оптимизировать свои коммиты для понимания - если вы вернетесь и прочитаете diff для фиксации, можете ли вы понять, что вы сделали в результате изменений?

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

  • Не выполняйте после каждого небольшого изменения - каждая строка изменена, каждый файл изменен и т.д.
  • Не работайте целый день и делайте одно гигантское коммит в конце дня.
  • Разделяйте коммиты для разных функций - например, разработка функции foo против исправления ошибки # 2.
  • Сделайте отдельную фиксацию для перемещения/переименования файлов, потому что проще Git отслеживать этот путь.
  • Подумайте об оптимизации для возвращаемости: если вам не нравится изменение, которое вы сделали, легко ли его отменить даже после того, как новые изменения были сведены сверху?

Ответ 2

"Легко понять" означает также:

  • фиксирует представление не только "контрольной точки" (например, если бы они были сделаны после каждой модификации файла), но когерентное состояние кода
  • easy to git bisect (т.е. каждая фиксация должна представлять собой изменение в задаче, которая компилирует и добавляет эволюцию или новую функцию, а не "фиксация контрольной точки", что приведет к тому, что git bisect не удастся слишком быстро).

См. " понимание рабочего процесса Git: для этого вам нужно различать:

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

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