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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

Смотри также:

Продолжаете ли вы разработку в ветке или в стволе

Стратегии ветвления

Answer 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?

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

Answer 4

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

• Лучшие практики контроля версий (мой собственный блог)
• Ранняя регистрация, частая регистрация (ужас кодирования) (комментарии содержат много полезных советов)
• Политика коммитов KDE

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

• Организация базы исходного кода при смешивании двух или более языков (например, Java и C ++)
• Предложения по правильному сообщению о коммите: format / guideline?
• Как часто совершать изменения в системе контроля версий?
• Обучение управлению версиями и его хорошее изучение

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

Answer 8

Эрик Синк, который появился на SO подкасте № 36 в январе 2009 года, написал отличную серию статей под названием Source Control How-to .

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

Answer 9

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

Как часто вы совершаете? Как часто вы нажимаете Ctrl + S?

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

Что такое ветка и что такое тег и как вы им управляете?

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

Стоит также упомянуть, что в subversion транк, ветви и теги являются только условными. Ничто не мешает вам выполнять работу в тегах или иметь ветви, которые являются вашей основной линией, или игнорировать схему tag-branch-trunk полностью вместе. Но, если у вас нет веских причин, лучше придерживаться соглашения.

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

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

Answer 10

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

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

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

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

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