Як користуватися SVN, відділенням? Тег? Стовбур?

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

Що я хотів би прояснити, це такі теми:

• Як часто ви здійснюєте вчинення? Настільки часто, як хтось натискав би Ctrl+ s?
• Що таке Відділення і що таке Тег і як ними керувати?
• Що переходить у СВН? Тільки вихідний код чи ви також ділитесь іншими файлами тут також? (Не вважається файлами з розширенням.)

Я не маю уявлення, що таке гілка та тег, тому я не знаю мети, але я дивно здогадуюсь, що ви завантажуєте речі на стовбур, а коли ви робите основну збірку, ви переміщуєте її до гілки? Отже, що вважається великою складовою в даному випадку?

Підривна книга є відмінним джерелом інформації про стратегію виклавши свій репозиторій, розгалуження і мічення.

Дивитися також:

Чи продовжуєте ви розвиток у гілці чи в стовбурі

Стратегії розгалуження

Я задавав собі ті ж запитання, коли ми прийшли здійснити Subversion тут - близько 20 розробників поширилися на 4 - 6 проектів. Я не знайшов жодного доброго джерела з "" відповіддю ". Ось деякі частини того, як наша відповідь розвивалася за останні 3 роки:

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

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

- ми навряд чи використовуємо теги, хоча вважаємо, що нам слід використовувати їх для визначення випусків у виробництво;

Подумайте, як розвиток проходить по одному шляху. Через деякий час маркетинг або стан розвитку вирішили випустити першу версію продукту, тому ви посадите прапор у шлях, позначений «1» (або «1,0», або що у вас є). В інший час якась яскрава іскра вирішує паралелізувати програму, але вирішує, що це займе тижні, і люди тим часом хочуть продовжувати йти основним шляхом. Таким чином, ви будуєте вилку на шляху і різні люди блукають по різних вилах.

Прапори на дорозі називаються «мітками», а вилки на дорозі - там, де розділяються «гілки». Інколи також гілки повертаються разом.

- ми поміщаємо весь матеріал, необхідний для складання виконуваного файлу (або системи) у сховище; Це означає принаймні вихідний код та файл (або файли проекту для Visual Studio). Але коли ми маємо піктограми та конфігураційні файли та все інше, що потрапляє у сховище. Деяка документація потрапляє в репо; звичайно, будь-яка документація, наприклад, довідкові файли, які можуть бути невід'ємними для програми, і це корисне місце для розміщення документації для розробників.

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

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

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

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

Ось кілька ресурсів щодо частоти фіксації, повідомлень про фіксацію, структури проекту, що потрібно поставити під контроль джерела та інших загальних рекомендацій:

• Кращі практики контролю версій (мій власний блог)
• Приїжджайте на початку, часто заїжджайте (кодування жахів) (коментарі містять багато корисних порад)
• Політика виконання зобов'язань KDE

Ці запитання щодо переповнення стека містять також корисну інформацію, яка може вас зацікавити:

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

Щодо основних концепцій субверсії, таких як розгалуження та тегування, я вважаю, що це дуже добре пояснено в книзі "Субверсія" .

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

Я не вважаю, що корисно застосовувати таку практику, якщо ви не розумієте її цілі або не погоджуєтесь з обґрунтуванням, що її лежить. Тому не дотримуйтесь жодних порад сліпо, а краще подумайте про те, що, на вашу думку, буде найкраще працювати для вас. Крім того, експериментувати з різними способами поведінки - це хороший спосіб навчитися та з’ясувати, як вам найбільше подобається працювати. Хорошим прикладом цього є те, як ви структуруєте сховище. Немає правильного чи неправильного способу це зробити, і часто важко зрозуміти, який саме спосіб ви віддаєте перевагу, поки ви фактично не випробували їх на практиці.

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

Гілки можна використовувати одним із двох способів, як правило: 1) одна активна гілка для розвитку (і стовбур залишається стабільною), або 2) гілки для альтернативних шляхів розвитку.

Теги, як правило, використовуються для ідентифікації випусків, тому вони не втрачаються в суміші. Визначення поняття "випуск" залежить від вас.

Я думаю, що головна проблема - це ментальна картина управління джерелами плутається. У нас зазвичай стовбур і гілки, але тоді ми отримуємо незв’язані уявлення про теги / релізи або щось на те, що впливає.

Якщо ви більш повно використовуєте ідею дерева, то це стає зрозумілішим, принаймні для мене це так.

Отримуємо стовбур -> форми гілок -> даємо плоди (теги / релізи).

Ідея полягає в тому, що ви вирощуєте проект із стовбура, який потім створює гілки, коли стовбур буде досить стійким, щоб утримувати гілку. Потім, коли гілка дала плід, ви виймаєте її з гілки і випускаєте як бирку.

Теги по суті є результатами. Тоді як стовбур і гілки виробляють їх.

Як вже говорили інші, книга SVN - найкраще місце для початку та чудова довідка, як тільки ви отримаєте свої морські ноги. Тепер, до ваших питань ...

Як часто ви здійснюєте вчинення? Як часто хтось натискатиме ctrl + s?

Часто, але не так часто, як ви натискаєте ctrl + s. Це питання особистого смаку та / або політики команди. Особисто я хотів би сказати, що ви виконуєте функціональний фрагмент коду, який би він був невеликим.

Що таке Відділення і що таке Тег і як ними керувати?

По-перше, багажник - це місце, де ви займаєтесь своїм активним розвитком. Це основна лінія вашого коду. Гілка - це деяке відхилення від основної лінії. Це може бути серйозне відхилення, як попередній випуск, або просто незначне налаштування, яке ви хочете спробувати. Тег - це знімок вашого коду. Це спосіб прикріпити мітку чи закладку до певної редакції.

Варто також зазначити, що в підривному процесі стовбур, гілки та мітки є лише умовою. Ніщо не заважає вам працювати над тегами або мати гілки, які є вашою основною лінією, або нехтувати схемою тег-гілка-магістраль разом. Але, якщо у вас немає дуже вагомих причин, краще дотримуватися умовності.

Що переходить у СВН? Тільки вихідний код чи ви також ділитесь іншими файлами тут також?

Також особистий або командний вибір. Я вважаю за краще зберігати в своєму сховищі все, що стосується збірки. Це включає в себе конфігураційні файли, скрипти збірки, пов'язані з медіа - файлів, документів і т.д. Ви повинні НЕ перевіряти файли , які повинні бути різними на машині кожного розробника. Також не потрібно перевіряти побічні продукти свого коду. Я здебільшого думаю про створення папок, файлів об’єктів тощо.

Ерік Сінк, який з’явився в подкасті SO # 36 в січні 2009 року, написав чудову серію статей під назвою " Як контролювати джерела" .

(Ерік є засновником SourceGear, який продає сумісну з plug-версією SourceSafe, але без жахливості.)

Просто додайте ще один набір відповідей:

• Я виконую обов'язки, коли закінчую роботу. Іноді це крихітний виправлення, який просто змінив один рядок і зайняв у мене 2 хвилини; в іншому випадку потіти два тижні. Крім того, як правило, ви не здійснюєте нічого, що порушує збірку. Таким чином, якщо вам знадобилося багато часу, щоб щось зробити, візьміть останню версію, перш ніж здійснити, і подивіться, чи ваші зміни порушують збірку. Звичайно, якщо я довго їду, не беручи на себе зобов'язань, мені це стає неприємно, тому що я не хочу втрачати цю роботу. У TFS я використовую цю приємну річ як "шевелюри" для цього. У SVN вам доведеться обійтися іншим способом. Можливо, створіть власну гілку або створіть резервну копію цих файлів вручну на іншій машині.
• Відділення - це копії всього вашого проекту. Найкращою ілюстрацією для їх використання є, мабуть, версія версії продуктів. Уявіть, що ви працюєте над великим проектом (скажімо, ядром Linux). Після місячних поту ви нарешті дійшли до версії 1.0, яку ви випускаєте для публіки. Після цього ви починаєте працювати над вашою версією 2.0, яка буде набагато кращою. Але в той же час там також багато людей, які використовують версію 1.0. І ці люди знаходять помилки, які вам доведеться виправляти. Тепер ви не можете виправити помилку у майбутній версії 2.0 та передати її клієнтам - вона зовсім не готова. Натомість вам потрібно витягнути стару копію джерела 1.0, виправити помилку там і надіслати її людям. Це те, для чого потрібні гілки. Коли ви звільнили 1. У версії 0 ви створили відділення у SVN, яке зробило копію вихідного коду в той момент. Ця галузь отримала назву "1,0". Потім ви продовжили роботу над наступною версією у вашій основній копії, але 1.0 копія залишилася там, якою вона була на момент випуску. І ви можете продовжувати виправляти помилки там. Теги - це лише імена, що додаються до певних версій для зручності використання. Можна сказати "Редакція 2342 вихідного коду", але простіше позначати це як "Перша стабільна версія". :)
• Зазвичай я вкладаю все в джерело управління, яке стосується безпосередньо програмування. Наприклад, оскільки я створюю веб-сторінки, я також розміщую зображення та файли CSS у керуванні джерелами, не кажучи вже про конфігураційні файли тощо. Проектна документація туди не надходить, проте це насправді лише питання переваги.

Інші заявили, що це залежить від вашого стилю.

Для вас велике питання - як часто ви "інтегруєте" своє програмне забезпечення. Тестовий розвиток, Agile та Scrum (та багато, багато інших) покладаються на невеликі зміни та постійну інтеграцію. Вони проповідують, що вносяться невеликі зміни, кожен знаходить перерви і постійно їх виправляє.

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

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

На це питання немає остаточної відповіді, найкращий спосіб - це працювати зі своєю командою, щоб придумати найкраще компромісне рішення.

Управління версіями з Subversion - це посібник як для початківців, так і для старих.

Я не думаю, що ви можете ефективно використовувати Subversion, не читаючи принаймні кілька перших розділів цього.

Для здійснення я використовую такі стратегії:

• вчиняйте якомога частіше.

• Кожна зміна / виправлення функції повинна отримати власний фіксатор (не вводите відразу багато файлів одразу, оскільки це зробить історію цього файлу незрозумілою - наприклад, якщо я зміню модуль реєстрації та модуль GUI самостійно, і я виконую обидва відразу, обидві зміни будуть видимі в обох історіях файлів. Це ускладнює читання історії файлів),

• не порушуйте збірку на будь-який комітет - слід отримати можливість отримати будь-яку версію сховища та створити її.

Усі файли, необхідні для створення та запуску програми, повинні бути у SVN. Тестові файли та інше не повинні, якщо вони не є частиною одиничних тестів.

Тут багато хороших коментарів, але те, що не згадувалося, - це повідомлення про вчинення. Вони повинні бути обов'язковими та змістовними. Особливо з розгалуженням / злиттям. Це дозволить вам відстежувати, які зміни стосуються функцій помилок.

наприклад, svn commit . -m 'bug #201 fixed y2k bug in code'скаже кожному, хто дивиться на історію, для чого це перегляд.

Деякі системи відстеження помилок (наприклад, trac) можуть шукати у сховищі ці повідомлення та пов’язувати їх із квитками. Що дозволяє легко розібратися, які зміни пов'язані з кожним квитком.

Політика в нашій роботі йде приблизно так (команда для багатьох розробників, що працюють на об'єктно-орієнтованій основі):

• Оновлення від SVN щодня, щоб отримати зміни за попередній день

• Здійснюйте щоденні дії, тому якщо ви хворі або відсутні на наступний день, хтось інший може легко перейняти місце, де ви зупинилися.

• Не вводьте код, який нічого не порушує, оскільки це вплине на інших розробників.

• Працюйте над маленькими шматками і щодня виконайте ЗМІСТНІ КОМЕНТАРИ!

• Як команда: Зберігайте гілку розвитку, а потім перемістіть код перед випуском (для якості) у відділення виробництва. Ця гілка повинна мати колись повністю працюючий код.

Посібник TortoiseSVN TSVN базується на підривній книзі , але доступний на набагато більше мов.

Я думаю, що існує два способи введення частоти:

1. Введіть дуже часто для кожного реалізованого методу невелику частину коду тощо.
2. Ввести лише завершені частини коду, як-от модулі тощо.

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