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

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

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

Ответы на вопрос(10)

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

а единица функциональности.

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

AFAIK) - один коммит на «логически отдельный набор изменений».

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

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

 25 июн. 2009 г., 12:48
Также вы бы хотели, чтобы каждая комитированная версия работала корректно (это помогает разделить пополам для поиска ошибок).
 29 июл. 2011 г., 11:39
если у вас есть проект, сделайте коммит, когда захотите. Если вы редактируете чужой проект, сделайте коммит, когда патч будет завершен
 06 дек. 2015 г., 05:22
Отличное замечание при проверке кода: если кто-то смотрит на коммит, который он должен посмотреть на одно решение или изменение, это изменение может быть в одном или нескольких файлах, но они связаны одной функциональностью или улучшением.

wordpress etc. I see that they do not commit that often.

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

 08 авг. 2013 г., 23:40
@baudtack: совсем нет. Перебазируйте безнаказанно, и если вы полностью испортили это, просто используйтеgit reflog а такжеgit reset чтобы вернуться туда, где вы были!
 23 сент. 2014 г., 10:59
git rebase совсем не опасно. Если вам нужна простая сеть безопасности перед выполнением ребазинга, создайте резервную ветку текущей HEAD сgit branch branchname.bck, Если вы не удовлетворены перебазированием, вернитесь в предыдущее состояние с помощьюgit reset --hard branchname.bck, Если вы хотите вернуться к перебазированной версии, повторные коммиты все еще существуют, но, поскольку они хранятся в виде объектов, на которые нет ссылок, вам потребуетсяgit reflog или жеgit fsck --no-reflogs найти правильные значения sha1.
 17 нояб. 2009 г., 01:11
Следует заметить, что git rebase, хотя и великолепен, является очень опасным инструментом, если вы не будете осторожны.
 18 февр. 2014 г., 01:00
@baudtack Есть ли аргументы для вашего заявления? (Я им не пользуюсь, но любопытно ради других).
 11 мар. 2015 г., 00:08
Пожалуйста, позвольте всем прекратить «ребаз» очень опасен ». мем. Опасные? Почти магия? Да! Различная общая история - это боль, да. Но следует поощрять использование собственной ветки для ясности коммитов! напримерjeffkreeftmeijer.com/2010/the-magical-and-not-harmful-rebase

ервного копирования»; ваш код, вы должны использовать tarballs или dropbox или что-то еще, чтобы гарантировать, что вы не потеряете код.

Если вы не делаете коммиты очень часто, вы можете лучше точно сказать, что должно происходить в коммите, и это даст вам более гладкую историю, чем 50 коммитов с

"К сожалению", "Черт", "забыл этот файл"

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

 23 авг. 2011 г., 17:37
Я считаю это анти-паттерном. Фиксируйте ранний коммит часто локально, затем сквош, прежде чем двигаться вверх по течению. Вы НЕ хотите потерять свою работу. Резервные копии предназначены для аппаратного сбоя, git - для сохранения каждого внесенного вами логического изменения таким образом, чтобы его можно было легко проверить и отменить.

Не забывайте, что вы могли бы скорее & quot;git add& Quot; функция за функцией, делая только один коммит:

once all the functions are written or fixed for a given task or once you realize the current function is too large/complicated to be part of a commit any time soon: you can then commit what is currently "on stage" ("git added"), which would not include your current modifications in the working directory.

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

local branch: go crazy, commit anytime you want "public" branch (one that you will push): for a local repository (for selected group of people): you could regroup at least the very small "intermediate" commits for a public repository (for all developers, or other projects to see): you can make an interactive rebase in order to regroup your commit by "activity" or "task" in order to make those more readable.

Короче говоря, & quot;publication соображения & Quot; может, вDVCS (как в «Распределенном») поможет вам правильно выбрать количество коммитов по правильным причинам.

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

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

 21 июл. 2011 г., 14:15
Ну, вы можете запустить "git add" часто для сохранения вашей работы, но только для фиксации, когда функция завершена.
 21 июл. 2011 г., 20:02
Но если вы не внесете эти локальные изменения, вы не сможете вернуться и просмотреть свою собственную работу.
 21 июл. 2011 г., 14:14
Пока коммиты все компиляции и существующие тесты проходят.
 28 февр. 2014 г., 16:47
@MariusK Да, я вроде как предполагаю, что вы не добавляете полностью нарушенный код в каноническую ветвь.

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

Ваш ответ на вопрос