Это то, как вы обычно используете SVN или GIt?

Question

Во всех уроках, которые я вижу по использованию SVN или Git, они всегда показывают, как обновляются отдельные файлы. Я могу работать с 100 файлами за 1 день, нормально ли работать со многими файлами и в конце дня просто сделать 1 коммит для всех файлов вместо того, чтобы делать каждый файл, который я изменяю?

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Меньшие коммиты лучше, когда вы и ваша команда тоже делаете обзор кода. Таким образом, вы фиксируете только 5, 10 файлов, и рецензент будет легче просматривать код. Если вы передадите 100 файлов, у рецензента будет гораздо больше работы.

Answer 5

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

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

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

Кроме того, он будет держать вас сосредоточенным на одной задаче за раз. Если вы сохраняете десятки изменений в своей голове одновременно, вы в конечном итоге что-то забудете. Отдавая изменения индивидуально, вы сможете сосредоточиться на качестве каждого изменения.

Answer 6

(отвечая на Subversion.)

Что ж, обычно считается идеальным фиксировать группу файлов как отдельное "изменение". Например. если вы работаете над сайтом и добавляете новое изображение на страницу, ваш коммит будет выглядеть примерно так:

$ svn add header.png
A   header.png
$ svn commit index.html header.png -m "Add new header to main page."
A   header.png
M   index.html
Revision 123 committed.

Это действительно делает историю хранилища более значимой, если данная ревизия соответствует отдельной функции, исправлению ошибки или рефакторингу (и т. Д.). Следует избегать двух вещей:

• Наличие более одного изменения в ревизии. Если вы передумаете об одном из изменений, его будет немного сложнее найти и отменить, не затрагивая другие изменения, связанные с ним.
• (Может быть, менее серьезно?) Изменение распространяется на несколько ревизий. Хорошо, если после каждой ревизии содержимое находится в работоспособном состоянии (что может означать, что оно может быть скомпилировано и, как правило, корректно для программы, или правильно сформированный HTML-код для веб-сайта). Это также означает, что легко отследить любое данное изменение для отмены или проверки.

Я знаю, что трудно запомнить это для всех изменений, и я был виновен в том, что совершил кучу несвязанных вещей с сообщением «изменения резервной копии разного» или чем-то таким же полезным. Это промахи и один или два не больно. Но действительно приятно видеть историю, которая гласит: «Редакция 1, Реализация X (измените A и добавьте B). Rev 2, Исправьте ошибку Y (измените C). Rev 3, Рефакторинг Z (измените D и E и переименуйте F» G). И т. д. "

Answer 7

Это нормально. Просто убедитесь, что код компилируется перед фиксацией. Техника называется «атомные коммиты», AFAIR. У него много преимуществ:

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

Обратите внимание, что реализация VCS практически не влияет на потребление пространства из-за большого количества коммитов.

Answer 8

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

Answer 9

Рассмотрим отдельные ветви для различных функций / ошибок

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

svn / git упрощает этот стиль ветвления, чем некоторые другие инструменты контроля версий.