Я установил репозиторий подрывной деятельности неправильно?

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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