Является ли контроль версий историей развертывания или историей разработки? - PullRequest
6 голосов
/ 03 декабря 2008

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

Является ли управление версиями истории развертывания или истории разработки?

Ответы [ 14 ]

8 голосов
/ 03 декабря 2008

Краткий ответ. Это оба.

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

3 голосов
/ 04 декабря 2008

Интересно, что никто еще не упоминал об использовании ветвления.

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

Это позволяет вам совершать обязательства рано и часто, не беспокоясь о том, испортили ли вы кого-то еще, и гарантирует, что у вас никогда не будет «я ушёл слишком далеко и не могу повернуть вспять» в этот момент при разработке чего-то нового, или, о боже, я потерял неделю, если ваш локальный диск должен умереть. (Само собой разумеется, что ваш репозиторий должен жить где-то, что часто резервируется!)

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

Это огромная привлекательность git для многих: очень легко разветвляться и объединяться, что позволяет просто отбрасывать новую ветку или даже ветки, когда они нужны. Даже CVS может выполнять ветвление и объединение, хотя это значительно более громоздко.

3 голосов
/ 03 декабря 2008

"Является ли контроль версий историей развертывания или историей разработки?"

Оба.

Редакции / версии файлов для разработчиков и ветки / теги / метки для развертывания.

Многое зависит от политики вашей организации.

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

Для централизованной системы вы, вероятно, не хотите проверять непроверенный / некомпилируемый код ...

опять же, это зависит от вашей организации.

3 голосов
/ 03 декабря 2008

Оба, но в первую очередь история развития. Ствол не должен постоянно находиться в развертываемом состоянии - это было бы безумием.

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

2 голосов
/ 03 декабря 2008

э-э, оба ...

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

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

Итак, в основном разработка, но также и внутренняя версия.

1 голос
/ 04 декабря 2008

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

Краткий ответ, оба при правильном использовании:)

1 голос
/ 03 декабря 2008

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

1 голос
/ 03 декабря 2008

Я думаю, что правильный ответ, вероятно, "это зависит":)

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

Некоторые системы контроля версий, такие как git и mercurial, и я думаю, что SVK (странно модифицированный SVN) позволяет вам иметь локальные репозитории, из которых вы можете получить предыдущие локальные версии. AFAIK, ни один из них не позволит вам откатиться, если вы хотя бы не зафиксировали свои изменения в своем локальном репо. Eclipse также позволяет вам выполнять откат к предыдущим версиям независимо от вашей системы контроля версий.

1 голос
/ 03 декабря 2008

Зависит от вас, вашей команды и ваших инструментов. Например, с централизованной системой управления версиями вы не должны фиксировать «сломанные» или «неполные» вещи, тогда как с распределенной вы можете делать это, и вы получите преимущества, если это сделаете. Смотрите здесь для более подробных (и интересных) примеров: http://bazaar -vcs.org / Workflows

0 голосов
/ 03 декабря 2008

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...