Имеет ли смысл фиксировать после каждого сохранения с DVCS?

Question

Я знаю, что вопрос задавался прежде, как часто совершать с DVCS. Все ответы имеют одну общую черту - как можно чаще. Но обычно это что-то вроде: после завершения размышления, пользовательской истории, получения кода, который компилируется, или прохождения тестов. Я думал, учитывая, что DVCS дает вам собственный репозиторий с очень дешевыми коммитами, разве не имеет смысла фиксировать после каждого изменения файла? В конце концов, это то, что происходит в NetBeans, и вы получаете хорошую бесплатную «машину времени», даже не прося об этом. Если не каждое изменение, то хотя бы каждое сохранение или компиляция.

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

Answer 1

Я использую инструмент git-wip для пользователей git и emacs. Он делает коммит каждый раз, когда я сохраняю, но делает коммит в боковой ветке. Автоматические коммиты не становятся частью истории в основной ветке и, следовательно, обычно не распространяются на другие репозитории.

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

Answer 2

Вам, безусловно, следует избегать написания кода, который не работает, а возможно, даже не компилируется (я думаю, даже если вы очистите историю с помощью git rebase --interactive перед отправкой / публикацией кода). В противном случае значение git bisect для поиска ошибок будет значительно уменьшено.

Вы можете использовать git commit + git commit --amend (или, например, stg refresh, если вы используете StGIT интерфейс управления патчами ¹ ) для создания снимка кода без введения коммитов с нерабочим ядром.

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

---

Сноска

^1. или эквивалент для других интерфейсов управления исправлениями, например Guilt для Git или Mercurial Queues * Расширение 1032 * (mq), распространяемое с Mercurial, которое было вдохновением для вины.

Answer 3

Это имело бы смысл, только если вы очистите свою историю раньше:

• подталкивание к любому другому репо
• или даже слияние / перебазирование его в любую другую ветку в вашем локальном репо.

Для этого вам нужно сообщение с общим префиксом, описывающим вашу текущую активность.
С помощью Git вы можете легко объединить все эти промежуточные коммиты в один.
См. " Обрезка GIT Checkins / Squashing GIT History " для получения дополнительной информации.

Answer 4

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

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

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

Answer 5

Один из стандартных программистов рефлекса состоит в том, чтобы нажать Ctrl + S (или: w). Если вы в конечном итоге будете иметь их в своей команде, в вашем репо будет огромное количество коммитов. Черт возьми, git-хэши даже не говорят прямо, сколько их.

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

Тем не менее, ничто не мешает вам сделать это с технической точки зрения. Git только добавляет больше объектов коммитов и указателей к BLOB-объектам, большинство из которых уже существует.

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