Я настроил Subversion Repository Неверно? - PullRequest
1 голос
/ 27 января 2012

Когда мы изначально настраивали контроль версий, у нас было очень ограниченное время и только базовые знания, как его настроить. Мы не понимаем ветви, стволы или теги. Все, с чем мы имеем дело, это Checkout, Update и Commit (о, и иногда конфликты).

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

В настоящее время на нашем сервере есть 4 разные папки, каждая из которых содержит извлечение. Эти 4 области имеют исходный код, который используется для производства. 2 из этих проверок работают непосредственно, как исправление ошибок. Другие 2 используются в качестве проверки разработки. Места, где член команды может работать над более длительным развитием. Как только они закончат разработку, они передают ее в хранилище и, таким образом, производственный код, который будет обновлен для всех остальных проверок.

Но когда вы читаете о ветвлении, это звучит как пропущенный уровень. Сундук, я думаю, что это называется.

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

Ответы [ 3 ]

1 голос
/ 27 января 2012

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

Что ж, ответ здесь - ответвления.В Subversion есть 2 разных типа веток, называемых ветвями и тегами.Они на самом деле одно и то же, но люди называют их разными именами, чтобы отличить использование, к которому вы их применили.

У вас есть транк, как и раньше, но теперь, когда разработчик хочет внести изменения, вы сначала делаетекопия сундука в новую ветку.Разработчик может работать все, что он хочет в этой отрасли безопасно.Как только он закончил, вы копируете изменения обратно в багажник.У Svn (и всех остальных) есть инструменты, которые помогут объединить изменения обратно в транк.

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

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

0 голосов
/ 27 января 2012

Попробуйте сначала прочитать несколько статей. Тогда возвращайтесь с более конкретными вопросами. Я думаю, что это хорошая статья: http://nvie.com/posts/a-successful-git-branching-model/

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

0 голосов
/ 27 января 2012

Этот ресурс, объясняющий ветви с графической визуализацией, может быть полезен для вас: http://nvie.com/posts/a-successful-git-branching-model/

...