Початок роботи з Контролем версій

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

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

Одне питання, яке я помітив у Git, полягає в тому, що не так багато повнофункціональних графічних інтерфейсів, що важливо для багатьох користувачів у моїй команді.

Крім того, не заперечуватимуть пропозиції щодо початку роботи з тим чи іншим. (навчальні посібники тощо)

Найголовніше у контролі версій:

ПРОСТО ПОЧНІТЬ ВИКОРИСТОВУВАТИ

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

З нього дуже легко конвертувати

cvs<->svn<->git<->hg

Не має значення, яку з них ви оберете. Просто виберіть найбільш простий для вас спосіб використання та почніть записувати історію коду. Ви завжди можете перейти на інший (D) VCS пізніше.

Якщо ви шукаєте простий у використанні графічний інтерфейс, перегляньте TortoiseSVN (Windows) та версії (Mac) (запропоновано codingwithoutcomments )

Редагувати:

pix0r сказав:

Git має кілька приємних функцій, але ви не зможете оцінити їх, якщо вже не використовували щось більш стандартне, як CVS або Subversion.

Це. Використовувати git безглуздо, якщо ви не знаєте, що контроль версій може зробити для вас.

Редагувати 2:

Щойно побачив це посилання на reddit: Subversion Cheat Sheet . Хороший короткий довідник для командного рядка svn.

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

Subversion Книга є кращим вибором для вивчення інструменту. Можуть бути й інші підручники з швидкого запуску, але Книга - найкраще окреме посилання, яке ви знайдете.

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

Якщо ви новачок у керуванні версіями, прочитайте це:
Source Control HOWTO

Перейти до SVN. Якщо ви ніколи раніше не користувалися контролем джерел, це не матиме значення для вас так чи інакше.

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

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

Перейти до SVN.

Для дружнього пояснення більшості основних концепцій див . Візуальний посібник з контролю версій . Стаття дуже зручна для SVN.

Я використовував RCS, CVS, SCCS, SourceSafe, Vault, perforce, subversion та git.

Я оцінив BitKeeper, Dimensions, arch, bazaar, svk, ClearCase, PVCS та Synergy.

Якби мені сьогодні довелося запустити нове сховище, я б вибрав git . Руки вниз.

Це безкоштовно, швидко та активно розвивається.

І ви можете використовувати його як клієнта будь-якого сховища диверсій, використовуючи git-svn.

Це скелі.

@ superjoe30

А як щодо керування джерелом на власному комп’ютері, якщо ви єдиний програміст? Це хороша практика? Чи є пов’язані поради чи підказки?

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

Вступ 5 секунд (за умови, що ви його встановили)

cd myproject
git init
git add * # add all the files
git commit

Наступного разу ви внесете деякі зміни

git add newfile1 newfile2 # if you've made any new files since last time
git commit -a

Поки ви це робите, git має вашу спину. Якщо ви зіпсуєте, ваш код безпечний у приємному сховищі git. Це приголомшливо

• Примітка: Можливо, вам буде важче витягнути речі з git, ніж їх отримати, але набагато краще мати цю проблему, ніж взагалі не мати файлів!

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

Тим не менш, можливо, починаючи з чистого аркуша за допомогою git, насправді може бути простіше - мій досвід роботи з VCS має централізований контроль версій (CVS, SVN, Perforce ...), і частина моїх (постійних!) Складностей з git була розуміння наслідків розподіленої моделі. Я коротко оглянув інші DVCS, такі як Bazaar та Mercurial, і вони, здавалося, були дещо зручнішими для новачків.

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

О, і не починайте з CVS. Він все ще застосовується на практиці і має переваги, але IMHO має занадто багато історичних примх та проблем реалізації (неатомні коміти!), Щоб бути хорошим способом навчання.

Мій голос йде за Subversion. Це дуже потужний, але простий у використанні і має кілька чудових інструментів, таких як TortoiseSVN .

Але, як казали інші до мене, ПРОСТО ПОЧНІТЬ ВИКОРИСТОВУВАТИ. Контроль джерел - це така важлива частина процесу розробки програмного забезпечення. Жоден "серйозний" програмний проект не повинен обійтися без нього.

На моїй поточній роботі мій попередник не використовував жодного виду контролю версій. Є просто гори папок принаймні в 3 різних місцях, де він зберігав усі свої проекти. Будь-яка випадкова папка проекту може знайти принаймні одну назву папки "проект (OLD)" та одну з іменем "проект"

За допомогою контролю версій вам ніколи не доведеться робити копії "безпечних" збірок. Вам насправді не потрібно турбуватися про те, що ваша IDE зіпсує файл, над яким ви працюєте (я дивлюсь на вас, REALBasic 5.5), тому що так легко виконувати (читати: зберігати) вашу роботу щодня.

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

Крім того, TortoiseSVN полегшує приєднання до бази даних так само просто, як клацання правою кнопкою миші папки.

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

Якщо ви використовуєте Mac OSX, я знайшов http://www.versionsapp.com/"> Версії неймовірним (безкоштовним) інтерфейсом графічного інтерфейсу до SVN.

Git перевершує диверсію, але трохи виходить із кровоточить краю.

Я б сказав, якщо ви тільки починаєте, стрибайте на край; створити безкоштовний обліковий запис @ http://github.com

Вони мають навчальний матеріал на сайті для налаштування та використання git.

Не чекай. Виберіть один і йдіть з ним. Усі системи матимуть свої плюси і мінуси. Ваше живлення може зникнути, ваш комп’ютер викрадений або ви забудете скасувати серйозні зміни, і весь ваш код смажиться, поки ви чекаєте, хто стане переможцем.

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

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

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

Так, SVN для переваги, якщо вам дійсно не потрібні особливі функції git. SVN досить важкий; Здається, з git складніше жити. Ви можете отримати розміщений svn від таких людей, як Beanstalk - якщо у вас немає власних людей Linux, я справді рекомендую його. Справа може піти не так просто, і приємно мати когось іншого, чия робота полягає в тому, щоб це виправити.

Є чудовий підручник з управління редакцією від Еріка Сінка, який варто прочитати незалежно від того, яку систему ви використовуєте.

Використовуйте TortoiseSVN (версія.app, якщо на mac). Просто встановіть і йдіть. Якщо вам потрібно місце для розміщення вашого коду, перегляньте веб-сторінку http://beanstalkapp.com/

SubVersion - найкращий вибір для вас, як зазначив Карл Сегін, перехід до іншої системи версій не буде проблемою. також SVN має дуже непоганий простий у використанні графічний інтерфейс на стороні клієнта (TortoiseSVN).

http://www.snee.com/bobdc.blog/2007/08/getting_started_with_subversio.html http://dojo.jot.com/WikiHome/Getting%20Started%20With%20Subversion

Якщо ви вирішите піти з підривом і хочете розмістити свій власний svn-сервер, то існує дуже приємний і простий сервер на базі Windows, який називається VisualSVN server. Це приховує складність налаштування сервера Apache, ви в основному просто переходите наступним наступним наступним. Конфігурація користувача обробляється веб-інтерфейсом замість конфігурації

http://www.visualsvn.com/server/

використовувати публічну службу rlike beanstalk, мабуть, простіше, але деякі люди люблять мати власні сховища, як для швидкості, так і для безпеки

У Coding Horror є чудова публікація про те, як налаштувати Subversion у Windows .

Після підручника я зміг запустити Subervsion і TortoiseSVN локально, і я отримав з цього необхідну освіту.

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

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

Тож я просто встановив для клієнта SVN-сервер і Tortoise SVN і занурився в поглиблене, і я не дізнався, як ним користуватися по дорозі.

Почніть використовувати SVN для своєї фактичної роботи, але спробуйте виділити час на базікання з Git та / або Mercurial. SVN досить стабільний для виробництва, але з часом ви зіткнетеся зі сценарієм, коли вам знадобиться розподілений SCM, до цього часу ви будете належним чином озброєні, а нові системи стануть досить зрілими.

superjoe30 пише :

Пов’язане запитання (можливо, відповіді також можна відредагувати, щоб відповісти на це питання):

А як щодо керування джерелом на власному комп’ютері, якщо ви єдиний програміст? >> Це хороша практика? Чи є пов’язані поради чи підказки?

Я використовую SVN для всіх своїх особистих проектів. Я почав із запуску svn на домашній машині, але врешті перейшов до Dreamhost. Їх хостингові пакети, які включають Subversion, є цілком розумними.

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

Я сам віддаю перевагу SVN, але це хороший варіант для швидкого використання.

Я б точно вибрав SVN замість CVS, хоча б тому, що люди, які навчились керуванню джерелами за допомогою CVS, зазвичай використовують " svn delete" тоді " svn add" замість " svn move". Що ускладнює пошук усіх попередніх версій конкретного файлу. І ви завжди можете перейти на використання git-svn. Я особисто вважаю, що це легше вчитися, ніж hg, але насправді основною причиною використання SVN є те, що він в основному став фактичною системою контролю версій програмного забезпечення з відкритим кодом.

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

@ superjoe30 Так, абсолют. Як тільки ви починаєте використовувати контроль версій, ви більше не повертаєтесь назад. Я використовую його для всього, навіть для своєї домашньої папки.

@Orion Edwards Subversion не вимагає сервера. Ви можете отримати доступ до локального сховища безпосередньо (звичайно, через клієнта), і жоден процес сервера не задіяний.

Просто використовуйте TortoiseSVN, і ви зможете жити навіть не знаючи фактичних команд Subversion ... Але це погано. На щастя, завжди буде «чудова можливість» вивчити їх напам'ять - коли ваш безцінний сховище вперше пошкодиться.

Так, буває.

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

Я б запропонував встановити Subversion Service замість того, щоб використовувати URL-адреси file: //, але це переважно особисті переваги. Для сховища, що зберігається на вашій машині розробки, файл: // чудово працює.

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