Вопрос по git, version-control, commit – частота мерзавцев

54

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

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

Ваш Ответ

10   ответов
6

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

2

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

-6

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

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

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

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

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

Не забывайте, что вы могли бы скорее & 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 (как в «Распределенном») поможет вам правильно выбрать количество коммитов по правильным причинам.

1

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

63

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

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

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

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

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

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

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

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

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

Но если вы не внесете эти локальные изменения, вы не сможете вернуться и просмотреть свою собственную работу.
Ну, вы можете запустить "git add" часто для сохранения вашей работы, но только для фиксации, когда функция завершена.
10
@MariusK Да, я вроде как предполагаю, что вы не добавляете полностью нарушенный код в каноническую ветвь.
Пока коммиты все компиляции и существующие тесты проходят.
3

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

Похожие вопросы