Я починаю зі SVN. Я знаю основні команди і розумію основні принципи. Мені було цікаво, чи є хто-небудь поради або найкращі практики роботи з Subversion в командному середовищі.
Я бачу вигоду від додавання розумно багатослівних повідомлень під час введення коду, але чи варто пам’ятати інші речі?
Дякую за всі чудові відповіді - вони дуже допомогли.
Відповіді:
Заохочуйте часті поступки. Співробітникам команди, які не користуються контролем версій, може здатися, що їм потрібно зберігати код із сховища, поки "він не працює правильно". Навчіть усіх брати на себе зобов’язання рано та часто знаходити проблеми якнайшвидше. Замість того, щоб утримувати код ", поки він не працює, запропонуйте вашим товаришам по команді створити гілки для функції, яка може зламати ствол. Це призводить до ...
Встановити практику розгалуження та маркування. Окрім гілок для функцій, заохочуйте своїх товаришів по команді використовувати гілки для виправлення великих помилок. Позначте виправлення основних помилок на початку та в кінці роботи. Підтримуйте теги (і, можливо, гілки) для виробництва / випусків qa.
Встановіть політику щодо ствола та дотримуйтесь його. Один із прикладів може бути: "Магістраль завжди повинна будуватися без помилок". або "ствол повинен завжди проходити всі одиничні тести". Будь-яка робота, яка ще не може відповідати стандартам багажника, повинна виконуватися у відділенні.
Не здійснюйте зміни форматування зі змінами коду
Якщо ви хочете реструктурувати пробіл гігантського файлу ( Control+ K+ D), добре. Зробіть зміни форматування окремо від фактичних логічних змін. Те саме стосується, якщо ви хочете переміщувати функції у файлах. Зробіть переміщення окремо від фактичного редагування.
Одне з ключових понять, до якого я завжди дотримуюся, - це разом здійснювати зміни коду . Слідство не вносити незв'язаних змін коду в один і той самий коміт . Це означає, що не виправляйте 2 помилки за один комітет (якщо це не те саме виправлення), а також не фіксуйте половину помилок у кожному з 2 комітів. Крім того, якщо мені потрібно додати якесь нове вдосконалення або щось у незв'язану частину системи, яка мені потім потрібна для якоїсь іншої роботи, я здійснюю удосконалення окремо (і спочатку). Ідея полягає в тому, що будь-яка зміна, яку хтось, можливо, захоче самостійно (або відкотити самостійно), має бути окремим зобов'язанням. Це допоможе вам заощадити тонни головного болю, коли прийде час робити злиття або відколювати порушені функції.
Багато вже було сказано, і ось ще кілька:
Якщо у вас є файли, які ви не бажаєте в керуванні джерелом (наприклад, конфігурація, компільовані файли тощо), додайте їх до списку ігнорування . Таким чином ви помічаєте будь-які файли, які ви забудете додати, завжди очікуючи порожнього списку файлів, що показують SVN як невідомі.
Додайте подію для фіксації публікації, яка надішле електронний лист до вашого списку розсилки розробників (або конкретного для цієї цілі), що стосується здійсненої зміни, а в ідеалі - виправлення для неї.
Інтегруйте свій інструмент відстеження помилок, щоб посилання на запити про помилки / функції відображалися із посиланнями на розріз. Це підтримують помилки, такі як MantisBT .
Подумайте про інтеграцію з постійною інтеграцією (наприклад, CruiseControl.NET ), NAnt for Build та NUnit / VS для одиничних тестів. Таким чином, як тільки код реєстрації користувача або в запланований інтервал збирається код, запускаються одиничні тести, і розробник отримує зворотній зв’язок про процес. Це також попередить решту команди, якщо сховище буде порушено (тобто не буде створено).
Ну, ази:
Відповіді, які люди дають, чудові. Значна частина цього узагальнена у користувальницькому документі svn для кращих практик для SVN .
Повторювати:
Я хотів би узагальнити кращі практики, яких я дотримуюся:
Має бути структура сховища . Особисто я використовую таку структуру репозиторію:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(пре-альфа), A(альфа), B(бета), AR(альфа-реліз), BR(бета-реліз), RC(кандидат на реліз), ST(стабільний).Ви можете ознайомитись з найкращими методами моєї підривної роботи у вигляді діаграми, що ілюструє основні принципи підходу до управління конфігурацією програмного забезпечення, який я використовую.
Одне, що я вважаю дуже корисним, це svn: external властивість, що означає, що ви можете посилати каталоги з інших сховищ у свої власні. Це дає дійсно приємні способи організації вашого коду та даних. Деякі приклади:
Використовуйте інтеграцію зі своїм програмним забезпеченням для відстеження помилок. Якщо ви використовуєте Bugzilla , ви можете налаштувати його, якщо ваш коментар починається з "Bug XXXX", ваш коментар SVN автоматично додається як коментар до даної помилки, включаючи посилання на ваш веб-інтерфейс SVN до цієї версії.
Дізнайтеся про інструменти та конвенції для розгалуження та об'єднання SVN.
Найкращий спосіб співпраці з іншими членами команди - це розбити роботу на цілісні характеристики / виправлення, а потім працювати над окремими змінами, кожен у галузі. Потім об'єднайте зміни назад до магістралі / магістралі, коли завершено / готово / затверджено для об'єднання.
Таким чином, люди можуть працювати над спільною метою (або на одній гілці, або окремо), не стикаючись з іншими змінами.
Ваш пробіг може відрізнятися, і це може бути надмірним для лише двох людей.
Це набагато простіше, якщо ви використовуєте хороші інструменти, які добре інтегруються з SVN. Вони дозволяють легко побачити, що було змінено, а потім здійснити всі або частину змін та часто оновлювати свою робочу копію до останньої версії в SVN.
Я рекомендую Tortoise SVN (якщо ви використовуєте Windows) та Visual SVN (якщо ви використовуєте VS).
Також перегляньте, чи можете ви налаштувати його так, щоб ви отримували електронну пошту чи подібне повідомлення будь-коли під час внесення змін (як правило, включаючи повідомлення про фіксацію та список змінених файлів). Такі послуги, як CVSDude, пропонують це. Мені корисно знати і те, що було зроблено оновлення, і потім мати деяке уявлення про те, що міститься в цьому оновленні, перш ніж оновити свою робочу копію.
Крім розгалуженої політики та ін. (де один розмір точно не підходить усім), ви повинні мати добрі результати:
Золоте правило контролю над джерелами: заїжджайте рано, заїжджайте часто
Поради щодо організації вашого сховища:
Проконсультуйтеся зі своєю командою щодо їх змін або, принаймні, дуже уважно подивіться на відмінності, перш ніж виправити будь-які конфлікти злиття. Попросіть їх самим переглянути об’єднаний код, щоб переконатися, що їхні доповнення не були втрачені в процесі злиття.
Я бачив одне, що зменшує кількість порушених комісій - це наявність хороших сценаріїв попереднього фіксації. Наприклад, ви можете запустити будь-які одиничні тести до зміни. Це призведе до того, що зобов’язання будуть трохи повільними, але ви економите час, уникаючи наступати на чиїсь пальці ніг і не потрібно вибачатися. Звичайно, це стає набагато важче керувати, коли у вас є велика команда розробників і дуже часті домовленості.
Одним із прикладів інтеграції з помилковим прослідковувачем та примусовим застосуванням політики може бути скрипт Trac 'svn до / після фіксації гачка, який може відмовитись від здійснення, якщо повідомлення комісії не посилається на будь-який квиток у баг-трекері та додає коментарі до існуючих квитки на основі вмісту повідомлення (тобто повідомлення про фіксацію може містити щось на зразок "Виправлення №1, №2 та №8", де №1, №2, №8 - номери квитків).
Найкраща практика використання SVN :
Коли ви вперше прийшли в офіс і відкрили проект Eclipse , перший крок повинен зробити - оновити проект.
Після оновлення приступайте до роботи. Закінчивши кодування, перевірте його, чи правильно працює програма без будь-яких винятків. Після того, як ви впевнені, що ваш код працює нормально, настав час зробити його.
Примітка. Під час здійснення коду не здійснюйте безпосередньо. Зробіть синхронізацію з сервером і перевірте, що потрібно зробити. Примітка. Не вкладайте всю папку один раз. Тому що ви, можливо, внесли деякі зміни до файлу для вашої вимоги або ви можете видалити деякі файли у вашій локальній системі. Але налаштування на сервері різні. Тому перевіряйте файли окремо і виконайте код.
Не здійснюйте / оновлюйте конфліктні файли безпосередньо
Коли робити заміщення та оновлення?
Коли ви майже впевнені, що вам не потрібні якісь ваші локальні зміни, і хочете повністю оновити копію сервера. Зауважте, що одного разу, якщо ви зробите переопрацювання та оновлення, ви не отримаєте жодних локальних змін.
Примітка. Не тримайте проект без оновлення більше доби. Також не зберігайте код, не виконуючи зобов'язання протягом багатьох днів.
Спілкуйтеся з тим, хто працює в одному складі, і обговоріть, які зміни вони вносять щодня.
Не встановлюйте властивості та файл конфігурації, якщо немає певних причин. Тому що налаштування будуть різними на сервері та в хмарі.
Не фіксуйте цільові папки у SVN, лише сховища вихідного коду та папки ресурсів повинні підтримуватися у сховищі SVN.
Коли ви втратили код, не панікуйте! Ви можете отримати попередню копію з історії SVN.
Не оформляйте проект у кількох місцях вашого диска. Оформіть його в одному місці та працюйте з ним.
SVN сам по собі є гарним початком, а деякі інші афіші запропонували чудові пропозиції щодо найкращих практик.
Єдине, що я хочу додати, це те, що вам слід підключити SVN за допомогою CruiseControl або TeamCity, щоб керувати процесом безперервної інтеграції. Це надсилатиме електронні електронні листи та повідомляє всіх, коли хтось порушив збірку.
Буде дуже рано говорити про те, хто слідкує за вашим процесом, а хто ні. Це може призвести до тертя, але в майбутньому ваша команда буде краще.
Точний коментар для кожного вчинку
Не порушуйте (основну) збірку!
Введіть, як тільки логічна одиниця зміниться
Уникайте використання Subversion як резервного інструменту
Трохи розгалуження / злиття, наскільки це можливо
.
Більш детальну інформацію можна знайти в кращих практиках SVN .
Пам’ятайте, що чим більше поступових, модульних, дискретних та лаконічних ви зробите свої зобов’язання, тим простіше вам (або, можливо, іншим):
Використовуйте це для шаблону коментарів:
[завдання / історія ххх] [другорядний / основний] [коментар] [подальший коментар] [URL для помилки]