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

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

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

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


git git-commit version-control
person loop    schedule 15.09.2011    source источник

Ответы (2)


arrow_upward
19
arrow_downward

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

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

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

  • Не фиксируйте каждое небольшое изменение - каждая строка, каждый файл и т. Д.
  • Не работайте целый день и сделайте одно гигантское обязательство в конце дня.
  • Делайте отдельные коммиты для разных функций - например, разработка функции foo против исправления ошибки №2.
  • Сделайте отдельную фиксацию для перемещения / переименования файлов, потому что Git легче отслеживать таким образом.
  • Подумайте об оптимизации для возможности возврата: если вам не нравится внесенное вами изменение, легко ли отменить его даже после того, как новые изменения были добавлены поверх?
person Nayuki    schedule 15.09.2011
comment
+1 особенно за понятие контроля версий как механизма записи, чтобы вы могли отменить отдельные изменения. - person tripleee; 15.09.2011
comment
Спасибо. Моя склонность к разделению логических изменений вызвана простотой использования git revert и git cherry-pick, а также Darcs ориентированный на изменения, а не на создание снимков. - person Nayuki; 15.09.2011
comment
Не совершайте фиксацию после каждого небольшого изменения, см. Следует ли мне фиксировать косметические изменения? - person MAChitgarha; 14.09.2018

arrow_upward
11
arrow_downward

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

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

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

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

Так что обратите внимание на "перемотку вперед" merge, который Git использует по умолчанию: не забудьте очистить историю веток, которые вы собираетесь объединить таким образом, в общедоступные ветки.

person VonC    schedule 15.09.2011
comment
+1 Я думаю, что пункт git bisect особенно важен - когда ваша история состоит из мельчайших коммитов, которые представляют изменения, которые имеют смысл вместе, деление ошибок пополам - это радость ... - person Mark Longair; 15.09.2011
comment
@test: цитата из статьи Понимание рабочего процесса Git, коммиты контрольных точек представляют собой частые коммиты, которые создают резервную копию вашей работы, но фиксируют код в нестабильном состоянии. Проблема с фиксацией контрольной точки не в том, что она включает один или несколько файлов, а в том, что она не представляет значимого изменения и (что еще хуже) может даже не компилироваться. И это создает проблемы для git bisect. - person VonC; 16.09.2011