Как использовать SVN, Branch? Тег? Хобот?

Я немного искал язык и не мог найти хорошего "новичка" для руководства SVN, а не в смысле "как я использую команды" скорее; Как я могу управлять своим исходным кодом?

Я хотел бы прояснить следующие темы:

  • Как часто вы совершаете? Как только вы нажимаете Ctrl + s?
  • Что такое ветвь и что такое тег, и как вы их контролируете?
  • Что входит в SVN? Только исходный код или вы также делитесь другими файлами? (Не считаются версиями файлов..)

Я не знаю, что такое ветка и тег, поэтому я не знаю цели, но моя дикая догадка заключается в том, что вы загружаете материал в багажник, и когда вы делаете крупную сборку, вы перемещаете ее в ветку? Итак, что считается важным в этом случае?

Ответы

Ответ 2

Я задал себе те же вопросы, когда мы пришли к реализации Subversion здесь - около 20 разработчиков распространялись по 4-6 проектам. Я не нашел ни одного хорошего источника с "ответом". Вот некоторые части того, как наш ответ развился за последние 3 года:

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

- мы используем ветки, как предполагал один из ваших предыдущих ответов, для разных путей развития; прямо сейчас для одной из наших программ у нас есть 3 активных ветки: 1 для основной разработки, 1 для еще еще незавершенных усилий по параллелизации программы и 1 для того, чтобы пересмотреть ее, чтобы использовать входные и выходные файлы XML;/p >

- мы почти не используем теги, хотя мы думаем, что мы должны использовать их для идентификации выпусков в производство;

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

Флаги на дороге называются "тегами", а вилки на дороге - "разветвления". Иногда также ветки возвращаются вместе.

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

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

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

Ответ 3

* How often do you commit? As often as one would press ctrl + s?

Как можно чаще. Код не существует, если он не находится под контролем источника:)

Частые коммиты (после этого меньшие наборы изменений) позволяют легко интегрировать ваши изменения и увеличивать шансы что-то не сломать.

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

Когда я работаю над своей веткой, я предпочитаю совершать как можно больше (буквально так же часто, как я нажимаю ctrl + s).

* What is a Branch and what is a Tag and how do you control them?

Прочтите книгу SVN - это место, с которым вы должны начать с изучения SVN:

* What goes into the SVN?

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

Ответ 4

Вот несколько ресурсов на частоте фиксации, фиксации сообщений, структуре проекта, том, что нужно поставить под контроль источника и других общих рекомендаций:

Эти вопросы также содержат полезную информацию, которая может представлять интерес:

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

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

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

Ответ 5

Частота фиксации зависит от стиля управления проектами. Многие люди воздерживаются от совершения, если он сломает сборку (или функциональность).

Ветви могут использоваться одним из двух способов: 1) одна активная ветвь для разработки (и соединительная линия остается стабильной) или 2) ветки для альтернативных путей dev.

Теги обычно используются для идентификации выпусков, поэтому они не теряются в миксе. Определение "релиз" зависит от вас.

Ответ 6

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

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

Мы получаем ветки ствола → формы → производим фрукты (теги/релизы).

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

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

Ответ 7

Как говорили другие, SVN Book - лучшее место для начала и отличная ссылка, как только вы получили свои морские ноги. Теперь, на ваши вопросы...

Как часто вы совершаете? Так часто, как один нажимать ctrl + s?

Часто, но не так часто, как вы нажимаете ctrl + s. Это вопрос личного вкуса и/или командной политики. Лично я бы сказал фиксацию, когда вы завершаете функциональную часть кода, пусть и маленькую.

Что такое ветвь и что такое тег, и как вы их контролируете?

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

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

Что входит в SVN? Только исходный код или вы совместно используете другие файлы?

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

Ответ 8

Эрик Синк, появившийся на SO подкасте № 36 в январе 2009 года, написал превосходную серию статей под заголовком "Руководство по управлению версиями" .

(Эрик является основателем SourceGear, который продает совместимую версию SourceSafe, но без ужаса.)

Ответ 9

Просто добавьте еще один набор ответов:

  • Я совершаю всякий раз, когда заканчиваю работу. Иногда это крошечный багфикс, который только что изменил одну строку и занял у меня 2 минуты; в других случаях это двухнедельный пот. Кроме того, как правило, вы не совершаете ничего, что нарушает сборку. Таким образом, если вам понадобилось много времени, чтобы сделать что-то, возьмите последнюю версию перед фиксацией и посмотрите, не изменились ли ваши изменения в сборке. Конечно, если я буду долгое время не совершать, это беспокоит меня, потому что я не хочу потерять эту работу. В TFS я использую эту приятную вещь как "shelvesets" для этого. В SVN вам придется работать по-другому. Возможно, создайте свою собственную ветку или создайте резервные копии этих файлов вручную на другой машине.
  • Филиалы - это копии всего вашего проекта. Лучшей иллюстрацией для их использования является, возможно, управление версиями продуктов. Представьте, что вы работаете над большим проектом (скажем, с ядром Linux). После нескольких месяцев пота вы наконец пришли к версии 1.0, которую вы публикуете для публики. После этого вы начнете работать над версией 2.0 вашего продукта, который будет лучше. Но в то же время есть много людей, которые используют версию 1.0. И эти люди находят ошибки, которые вам нужно исправить. Теперь вы не можете исправить ошибку в предстоящей версии 2.0 и отправить ее клиентам - она ​​совсем не готова. Вместо этого вам нужно вытащить старую копию источника 1.0, исправить там ошибку и отправить ее людям. Для этого нужны отрасли. Когда вы выпустили версию 1.0, вы сделали ветку в SVN, которая сделала копию исходного кода в этой точке. Эта ветка была названа "1.0". Затем вы продолжили работу над следующей версией в своей основной исходной копии, но версия 1.0 осталась там, как это было в момент выпуска. И вы можете продолжать исправлять ошибки там. Метки - это просто имена, прикрепленные к конкретным версиям для удобства использования. Вы можете сказать "Редакция 2342 исходного кода", но проще назвать ее "Первой стабильной ревизией".:)
  • Я обычно помещаю все в исходный элемент управления, который напрямую связан с программированием. Например, поскольку я создаю веб-страницы, я также помещаю изображения и файлы CSS в исходный элемент управления, не говоря уже о файлах конфигурации и т.д. Документация по проекту не идет туда, однако на самом деле это просто вопрос предпочтения.

Ответ 10

Другие заявили, что это зависит от вашего стиля.

Большой вопрос для вас - это то, как часто вы "интегрируете" свое программное обеспечение. Разработка, основанная на тестах, Agile и Scrum (и многие, многие другие) основаны на небольших изменениях и непрерывной интеграции. Они проповедуют, что сделаны небольшие изменения, каждый находит перерывы и исправляет их все время.

Однако в более крупном проекте (думаю, правительство, защита, 100k + LOC) вы просто не можете использовать непрерывную интеграцию, поскольку это невозможно. В этих ситуациях лучше использовать ветвление, чтобы делать много мелких коммитов, но только возвращать в багажник, что будет работать и готово к интеграции в сборку.

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

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

Ответ 11

Управление версиями с Subversion является руководством для начинающих и старых рук.

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

Ответ 12

Для фиксации я использую следующие стратегии:

  • совершать как можно чаще.

  • Каждое изменение функции /bugfix должно получить свою собственную фиксацию (не передавать сразу несколько файлов, так как это сделает историю для этого файла неясной - например, если я изменю модуль регистрации и модуль графического интерфейса самостоятельно и Я фиксирую оба одновременно, оба изменения будут видны в обеих историях файлов, что затрудняет чтение истории файла),

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

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

Ответ 13

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

Например, svn commit . -m 'bug #201 fixed y2k bug in code' расскажет всем, кто смотрит историю, на что эта ревизия была.

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

Ответ 14

Политика в нашей работе идет так (команда разработчиков с несколькими разработчиками работает над объектно-ориентированной средой):

  • Обновление от SVN каждый день для получения изменений предыдущего дня

  • Ежедневно делайте ставку, если вы больны или отсутствуете на следующий день (ы), кто-то другой может легко взять верх с того места, где вы остановились.

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

  • Работайте над маленькими кусками и совершайте ежедневные СООБЩЕНИЯ ПОСЛЕДНИЕ КОММЕНТАРИИ!

  • Как команда: держите ветку развития, а затем переместите код предварительного выпуска (для QA) в отдел производства. Эта ветка должна иметь только рабочий код.

Ответ 16

Я думаю, что есть два способа установить частоту:

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

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