Я використовую Subversion кілька років, і після використання SourceSafe я просто люблю Subversion. У поєднанні з TortoiseSVN я не можу реально уявити, як це може бути краще.
І все ж зростає кількість розробників, які стверджують, що у Subversion є проблеми і що ми повинні перейти до нової породи розподілених систем управління версіями, таких як Git .
Як Git покращується після підриву?
Відповіді:
Git не кращий, ніж Subversion. Але теж не гірше. Це інакше.
Ключова відмінність - децентралізація. Уявіть, що ви розробник в дорозі, ви розвиваєтеся на своєму ноутбуці і хочете мати управління джерелом, щоб ви могли повернутися на 3 години назад.
З програмою Subversion виникла проблема: сховище SVN може знаходитись у тому місці, куди ви не можете дістатися (у вашій компанії, і у вас немає Інтернету на даний момент), ви не можете скористатися. Якщо ви хочете зробити копію свого коду, вам доведеться його буквально скопіювати / вставити.
З Git у вас немає цієї проблеми. Ваша локальна копія є сховищем, і ви можете взяти на себе зобов’язання та отримати всі переваги контролю джерела. Коли ви відновите підключення до основного сховища, ви можете скористатися ним.
Спочатку це добре виглядає, але просто пам’ятайте про додаткову складність цього підходу.
Здається, Git - це "нова, блискуча, класна" річ. Це аж ніяк не погано (є причина, що Лінус все-таки написав це для розробки ядра Linux), але я відчуваю, що багато людей стрибають на поїзді "Розподілений контроль над джерелами" тільки тому, що він новий і написаний Лінусом Торвальдсом, фактично знаючи, чому / якщо краще.
Субверсія має проблеми, але Git, Mercurial, CVS, TFS або інше.
Редагувати: Тож ця відповідь зараз вже рік і все ще приносить багато результатів, тому я подумав, що я ще додаю пояснення. За останній рік з моменту написання цього повідомлення Git набрав чимало обертів та підтримки, тим більше, що сайти на зразок GitHub справді зняли. Я зараз використовую і Git, і Subversion, і я хотів би поділитися особистою думкою.
Насамперед, Git спочатку може бути дуже заплутаним, коли працює децентралізовано. Що таке пульт? і Як правильно налаштувати початковий сховище? два питання, які виникають на початку, особливо порівняно з простим "svnadmin create" SVN, "git init" Гіта може приймати параметри --bare та --shared, що, здається, є "правильним" способом налаштування централізованого сховище. Для цього є причини, але це додає складності. Документація команди "checkout" дуже заплутує людей, які змінюються - "правильний" спосіб, здається, "git clone", тоді як "git checkout", здається, перемикає гілки.
Git дійсно світить, коли ви децентралізовані. У мене вдома є сервер і ноутбук на дорозі, і SVN тут просто не працює. З SVN я не можу керувати локальним джерелом, якщо я не підключений до сховища (Так, я знаю про SVK або про способи копіювання репо). Що стосується Git, це все одно за замовчуванням. Це додаткова команда (git commit здійснює локально, тоді як git push origin origin поштовхує ведучу гілку до віддаленого під назвою "origin").
Як було сказано вище: Git додає складності. Два режими створення сховищ, checkout vs. clone, commit vs. push ... Ви повинні знати, які команди працюють локально, а які працюють із "сервером" (я припускаю, що більшість людей все ще люблять центральний "master-сховище" ).
Також інструментарій все ще недостатній, принаймні для Windows. Так, є Visual Studio AddIn, але я все ще використовую git bash з msysgit.
SVN має перевагу в тому, що це набагато простіше в освоєнні: є ваше сховище, всі зміни до нього, якщо ви знаєте, як створити, здійснити та здійснити замовлення, і ви готові піти і можете піклувати такі речі, як розгалуження, оновлення тощо пізніше на.
Перевага Git має те, що він набагато краще підходить, якщо деякі розробники не завжди підключені до основного сховища. Крім того, це набагато швидше, ніж SVN. І з того, що я чую, підтримка розгалуження та об'єднання є набагато кращою (чого можна очікувати, оскільки це основні причини, про які вона написана).
Це також пояснює, чому він набуває стільки гудів в Інтернеті, оскільки Git ідеально підходить для проектів з відкритим кодом: Просто Fork it, введіть свої зміни у власний Fork, а потім попросіть оригінального технічного керівника проекту здійснити зміни. З Git це просто працює. Дійсно, спробуйте це на Github, це магія.
Я також бачу мости Git-SVN: Центральний сховище - це репортаж Subversion, але розробники локально працюють з Git і міст потім підштовхує їх зміни до SVN.
Але навіть із цим довгим доповненням я все ще стою свого основного повідомлення: Git не кращий чи гірший, він просто інший. Якщо у вас є потреба у "Офлайн-контролі джерел" та бажання витратити трохи додаткового часу на її вивчення, це фантастично. Але якщо у вас суворо централізований контроль над джерелами та / або ви намагаєтесь запровадити контроль над джерелом, в першу чергу через те, що ваші колеги не зацікавлені, то простота та відмінна інструментальність (принаймні для Windows) SVN-блиску.
З Git ви можете робити практично все, що не в режимі офлайн, тому що кожен має своє сховище.
Зробити гілки та злиття між гілками справді просто.
Навіть якщо у вас немає прав на виконання зобов’язань щодо проекту, ви все одно можете мати власне сховище в Інтернеті та публікувати "push-запити" для своїх патчів. Усі, хто любить ваші патчі, можуть втягнути їх у свій проект, включаючи офіційних технічних працівників.
Тривіально розкладати проект, змінювати його та продовжувати об’єднуватись у виправленнях із гілки HEAD.
Git працює для розробників ядра Linux. Це означає, що це дійсно швидко (це повинно бути) і масштабується до тисяч учасників. Git також використовує менше місця (до 30 разів менше місця для сховища Mozilla).
Git дуже гнучкий, дуже TIMTOWTDI (Існує більше ніж один спосіб зробити це). Ви можете використовувати будь-який робочий процес, який хочете, і Git підтримуватиме його.
Нарешті, є GitHub , чудовий сайт для розміщення ваших сховищ Git.
Недоліки Git:
Інші відповіді добре зробили пояснення основних особливостей Git (які чудово). Але є також так багато маленьких способів, що Git веде себе краще і допомагає зберегти життя більш здоровим. Ось деякі дрібниці:
git mvі git rm.
" Чому Git кращий за X " окреслює різні плюси та мінуси Git та інших SCM.
Коротко:
Є деякі недоліки:
У найбільш спрощеному використанні Subversion і Git майже однакові. Існує не велика різниця між:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
і
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Де Git дійсно світить, це розгалуження та робота з іншими людьми.
Google Tech Talk: Лінус Торвальдс на git
http://www.youtube.com/watch?v=4XpnKHJAok8
Сторінка порівняння Git Wiki
Ну, це розподілено. Орієнтовні показники вказують на те, що це значно швидше (зважаючи на його розподілений характер, такі операції, як "diff" і "журнали", - це все локально, тому, звичайно, в цьому випадку це надзвичайно швидше), а робочі папки - менші (що все ще дує мені на думку).
Коли ви працюєте над підривною роботою або будь-якою іншою системою управління ревізією клієнт / сервер, ви, по суті, створюєте робочі копії на своєму пристрої, перевіряючи версії Це представляє момент часу, як виглядає сховище. Ви оновлюєте свою робочу копію за допомогою оновлень та оновлюєте сховище через коміти.
При розподіленому контролі версій у вас немає знімка, а всього кодової бази. Хочете зробити відмінності з 3-місячною версією? Немає проблем, тримісячна версія все ще на вашому комп’ютері. Це не означає, що все проходить швидше, але якщо ви від'єдналися від центрального сервера, ви все одно можете зробити багато операцій, до яких ви звикли. Іншими словами, ви маєте не просто знімок даної версії, а всю кодову базу.
Ви б могли подумати, що Git займе купу місця на вашому жорсткому диску, але з кількох тестів, які я бачив, це насправді займає менше. Не питайте мене, як. Я маю на увазі, що його побудував Лінус, він знає щось про файлові системи, я думаю.
Основні моменти, які мені подобаються у DVCS, це:
Основна причина відносно великого проекту - вдосконалене спілкування, створене пунктом 3. Інші - приємні бонуси.
Найцікавіше: я розміщую проекти в Subversion Repos, але отримую доступ до них за допомогою команди Git Clone.
Будь ласка, прочитайте « Розвиток з Git» у проекті Google Code
Хоча Google Code споконвічно говорить про Subversion, ви можете легко використовувати Git під час розробки. Пошук "git svn" передбачає, що ця практика є широко поширеною, і ми також радимо вам експериментувати з нею.
Використання Git у сховищі Svn дає мені переваги:
backup/public сховище svn, щоб інші могли перевіритиУсі відповіді тут, як очікувалося, орієнтовані на програміста, але що станеться, якщо ваша компанія використовує контроль редагування поза вихідним кодом? Є багато документів, які не є вихідним кодом, які користуються контролем версій, і повинні жити близько до коду, а не в іншій CMS. Більшість програмістів не працюють ізольовано - ми працюємо для компаній як частина команди.
Зважаючи на це, порівняйте простоту використання як в інструментах для клієнтів, так і в навчанні, між Subversion і git. Я не бачу сценарію, де такий є розподілена система контролю версій буде простішою у використанні або поясненні непрограміста. Мені б хотілося, щоб я виявився неправильним, тому що тоді я зміг би оцінити git і насправді сподіваюся, що він буде прийнятий людьми, які потребують контролю версій, а не програмістами.
Навіть тоді, якщо мене запитають керівництво, чому ми повинні перейти від централізованої до розподіленої системи контролю ревізії, мені було б важко дати чесну відповідь, тому що вона нам не потрібна.
Відмова: Я зацікавився Subversion рано (близько v0.29), тому явно я упереджений, але компанії, над якими працював з того часу, користуються моїм ентузіазмом, тому що я заохочував і підтримував його використання. Я підозрюю, що так відбувається з більшістю програмних компаній. Оскільки так багато програмістів стрибає на смузі git, мені цікаво, скільки компаній збирається пропустити переваги використання версій за межами вихідного коду? Навіть якщо у вас є окремі системи для різних команд, вам не вистачає деяких переваг, таких як (уніфікована) інтеграція відстеження випусків, при цьому збільшуються вимоги до технічного обслуговування, обладнання та навчання.
Subversion - це все-таки набагато більш використовувана система контролю версій, що означає, що вона має кращу підтримку інструментів. Ви знайдете зрілі плагіни SVN майже для будь-якого IDE , і є хороші розширення для дослідників (наприклад, TurtoiseSVN). Крім цього, мені доведеться погодитися з Майклом : Git не кращий і не гірший, ніж Subversion, він інший.
Одна з речей про SubVersion, яка мене дратує, - це те, що він розміщує власну папку у кожному каталозі проекту, тоді як git містить лише одну у кореневому каталозі. Це не така вже й велика угода, але такі дрібниці, як ця, складаються.
Звичайно, у SubVersion є черепаха, що [зазвичай] дуже приємно.
Блог Девіда Річардса WANdisco про Subversion / GIT
Виникнення GIT принесло із собою породу фундаменталістів DVCS - "Gitterons" - які думають, що будь-що, крім GIT, - це лайно. Gitterons, здається, думає, що інженерія програмного забезпечення відбувається на власному острові і часто забувають, що більшість організацій не використовують виключно старших програмних інженерів. Це нормально, але це не так, як думає решта ринку, і я радий це довести: GIT, при останньому погляді мав менше трьох відсотків ринку, тоді як Subversion має в районі п'ять мільйонів користувачів і близько половини загальний ринок.
Проблема, яку ми побачили, полягала в тому, що Гіттерони вистрілювали (дешеві) постріли на Subversion. Твіти на зразок "Підривність настільки [повільна / хитра / обмежувальна / не пахне добре / дивиться на мене смішно], і тепер у мене є ГІТ і [все працює в моєму житті / моя дружина завагітніла / я отримала подругу після 30 років спроб / я вигравав шість разів бігаючи за столом блекджек]. Ви отримуєте картину.
Git також робить розгалуження та злиття дійсно простим. Subversion 1.5 лише додав відстеження злиття, але Git все ще краще. З гітом розгалуження дуже швидко і дешево. Це робить створення філії для кожної нової функції більш можливим. Репозиторії Oh та Git дуже ефективні з простором зберігання в порівнянні з Subversion.
Вся справа в простоті використання / кроках, необхідних для того, щоб щось зробити.
Якщо я розробляю окремий проект на своєму ПК / ноутбуці, git краще, оскільки налаштувати та використовувати його набагато простіше. Вам не потрібен сервер, і вам не потрібно тримати введення URL-адреси сховища під час злиття.
Якби це було всього 2 людини, я б сказав, що git також простіше, тому що ви можете просто штовхатись і тягнути з одного.
Як тільки ви вийдете за рамки цього, я б пішов на підрив, тому що в цей момент вам потрібно встановити "виділений" сервер або місцеположення.
Це можна зробити так само добре з git, як і з SVN, але переваги git переважуються необхідністю робити додаткові кроки для синхронізації з центральним сервером. У SVN ви просто здійснюєте. У git ви повинні git фіксувати, а потім git push. Додатковий крок стає дратівливим просто тому, що ви в кінцевому підсумку робите це так сильно.
SVN також має переваги кращих інструментів графічного інтерфейсу, однак, екосистема git наздоганяє швидко, тому я не переживаю з цього приводу.
Easy Git має хорошу сторінку, де порівнюється фактичне використання Git та SVN, що дасть вам уявлення про те, що Git може робити (або робити легше) порівняно зі SVN. (Технічно це базується на Easy Git, який є легкою обгорткою поверх Git.)
Git та DVCS взагалі чудово підходять для розробників, які роблять багато кодування незалежно один від одного, оскільки кожен має свою галузь. Якщо вам потрібна зміна від когось іншого, вона має взяти на себе зобов’язання зі своїм місцевим репо, і тоді вона повинна підштовхнути цей набір змін до вас, або ви повинні витягнути його з неї.
Мої власні міркування також змушують мене думати, що DVCS ускладнює QA та управління випусками, якщо ви робите такі речі, як централізовані версії. Хтось повинен нести відповідальність за те, щоб робити це натискання / витягування з сховища всіх інших, вирішуючи будь-які конфлікти, які були б вирішені на початковому рівні фіксації раніше, потім роблять збірку, а потім мають всі інші розробники повторно синхронізувати свої репозиції.
З усім цим можна зрозуміти, звичайно, людські процеси; DVCS просто зламав щось, що було виправлено централізованим контролем версій, щоб забезпечити нові зручності.
Мені подобається Git, оскільки він фактично допомагає розробнику комунікацій розвиватися в середньому та великому колективі. Як розподілена система управління версіями, через систему push / pull система допомагає розробникам створити екосистему вихідного коду, яка допомагає керувати великим набором розробників, що працюють над одним проектом.
Наприклад, ви говорите, що ви довіряєте 5 розробникам і лише витягуєте коди зі свого сховища. Кожен з цих розробників має власну довірчу мережу, звідки вони витягують коди. Таким чином, розробка базується на тій структурі довіри розробників, де відповідальність за кодом розподіляється між спільнотою розробників.
Звичайно, є й інші переваги, про які йдеться в інших відповідях.
Кілька відповідей на це натякали, але я хочу зробити 2 пункти явними:
1) Можливість робити вибіркові коміти (наприклад, git add --patch ). Якщо ваш робочий каталог містить декілька змін, які не є частиною однієї логічної зміни, Git дозволяє дуже легко зробити фіксацію, що включає лише частину змін. З Subversion це важко.
2) Можливість вчиняти без оприлюднення змін. У програмі Subversion будь-яке зобов'язання негайно є загальнодоступним і, таким чином, безповоротним. Це значно обмежує можливість розробника "рано чинити, часто вчиняти".
Git - це більше, ніж просто VCS; це також інструмент для розробки патчів. Субверсія - це лише VCS.
Я думаю, що Subversion є чудовою, поки ви не почнете зливатись .. або робити щось складне .. або робити що-небудь. Subversion вважає складним (як, наприклад, робити запити, щоб дізнатися, які гілки переплутані з певним файлом, звідки насправді відбувається зміна , виявлення копії та паст тощо) ...
Я не погоджуюся з виграшною відповіддю, кажучи, що головна перевага GIT - робота в режимі офлайн - це, безумовно, корисно, але це більше нагадує додатковий випадок для мого використання. SVK може працювати і в автономному режимі, але для мене не виникає жодних питань, в який можна вкласти свій час навчання).
Просто це неймовірно потужне і швидке, і, добре звикаючи до понять, - дуже корисно (так, в цьому сенсі: дружнє до користувачів).
Детальніше про історію злиття див. У цьому: Використання git-svn (або подібного) * просто *, щоб допомогти зі злиттям svn?
Завдяки тому, що йому не потрібно постійно спілкуватися з центральним сервером, майже кожна команда працює менше ніж за секунду (очевидно, що git push / pull / fetch відбувається повільніше, просто тому, що їм належить інталізувати SSH-з'єднання). Розгалуження набагато простіше (одна проста команда для розгалуження, одна проста команда для об'єднання)
Я абсолютно люблю вміти керувати локальними відділеннями мого вихідного коду в Git, не замулюючи воду центрального сховища. У багатьох випадках я перевіряю код із сервера Subversion і запускаю локальне сховище Git просто для того, щоб це зробити. Також чудово, що ініціалізація сховища Git не забруднює файлову систему купою дратівливих папок .svn скрізь.
Що стосується підтримки інструментів Windows, TortoiseGit дуже добре поводиться з основами, але я все ж віддаю перевагу командному рядку, якщо я не хочу переглянути журнал. Мені дуже подобається, як Tortoise {Git | SVN} допомагає читати журнали фіксації.
Це неправильне запитання. Все занадто просто зосередитись на бородавці болячок і сформулювати аргумент щодо того, чому підрив нібито кращий, принаймні для деяких випадків використання. Той факт, що git спочатку був сконструйований як низькорівневий набір конструкцій управління версією та має бароковий інтерфейс, орієнтований на Linux, розробник, що полегшує святі війни війнам та сприйняттям легітимності. Прихильники Git трясуть барабан мільйонами переваг робочого процесу, які svn хлопці вважають непотрібними. Досить скоро вся дискусія формулюється як централізована проти розподіленої, що відповідає інтересам спільноти інструментів підприємства svn. Ці компанії, які зазвичай викладають найпереконливіші статті про перевагу підривної діяльності на підприємстві,
Але ось проблема: Subversion - це архітектурна тупик .
Тоді як ви можете взяти git і створити централізовану заміну підривної системи досить легко, незважаючи на те, що існує довше ніж удвічі довше, ніж svn ніколи не вдавалося отримати навіть базове відстеження злиття, яке працює в будь-якому місці поблизу, як і в git. Однією з основних причин цього є дизайнерське рішення зробити гілки такими ж, як і каталоги. Я не знаю, чому вони пішли цим шляхом спочатку, але це, звичайно, робить часткові каси дуже простими. На жаль, це також робить неможливим належне відстеження історії. Тепер, очевидно, ви повинні використовувати умовні верстки макетів реверсійного підриву для відділення гілок від звичайних каталогів, а svn використовує деякі евристики для того, щоб все працювало у випадках щоденного використання. Але все це лише обґрунтування дуже поганого та обмежувального дизайнерського рішення низького рівня. Можливість робити різний сховище (а не розрізнення в каталозі) - це основна і важлива функціональність для системи управління версіями, і значно спрощує внутрішні системи, що дозволяє будувати розумніші та корисні функції поверх неї. Ви можете бачити вкладені зусилля, що вкладаються в розширення підриву, і все ж, наскільки це відстає від поточного врожаю сучасних VCSes в таких фундаментальних операціях, як дозвіл на злиття.
Ось моя серцева та агностична порада для тих, хто все ще вважає, що Subversion є достатньою для огляду в майбутньому:
Субверсія ніколи не наздожене новіші породи ВКС, які навчилися на помилках RCS та CVS; це технічна неможливість, якщо вони не переобладнають модель сховища з нуля, але тоді це насправді не було б svn, чи не так? Незалежно від того, наскільки ви думаєте, що не володієте можливостями сучасного VCS, ваше незнання не захистить вас від підводних каменів Subversion, багато з яких є ситуаціями, які неможливо або легко вирішити в інших системах.
Вкрай рідко є технічна неповноцінність рішення настільки чітко, як це стосується svn, звичайно, я б ніколи не висловлював такої думки щодо win-vs-linux чи emacs-vs-vi, але в цьому випадку це так clearcut та управління джерелами - це настільки фундаментальний інструмент в арсеналі розробника, що я вважаю, що це потрібно заявити однозначно. Незалежно від вимоги використовувати svn з організаційних причин, я закликаю всіх користувачів svn не допускати, щоб їх логічний розум побудував помилкове переконання, що більш сучасні VCS корисні лише для великих проектів з відкритим кодом. Незалежно від характеру вашої роботи з розробки, якщо ви програміст, ви будете більш ефективним програмістом, якщо навчитеся використовувати краще розроблені VCSes, будь то Git, Mercurial, Darcs або багато інших.
Subversion дуже простий у використанні. За останні роки я ніколи не знаходив жодної проблеми або щось не працює так, як очікувалося. Крім того, існує багато чудових інструментів GUI, і підтримка інтеграції у SVN є великою.
За допомогою Git ви отримуєте більш гнучкий VCS. Ви можете використовувати його так само, як SVN, з віддаленим сховищем, де ви здійснюєте всі зміни. Але ви також можете використовувати його в основному в режимі офлайн і лише час від часу пересилати зміни до віддаленого сховища. Але Git є більш складним і має більш круту криву навчання. Я вперше опинився на неправильних гілках, створюючи гілки опосередковано або отримую повідомлення про помилки, не надто багато інформації про помилку, і де мені потрібно шукати в Google, щоб отримати кращу інформацію. Деякі прості речі, такі як заміна маркерів ($ Id $), не спрацьовують, але GIT має дуже гнучкий механізм фільтрації та підключення для об'єднання власних сценаріїв, тому ви отримуєте все необхідне та інше, але для цього потрібно більше часу та читання документації. ;)
Якщо ви працюєте в основному в автономному режимі з локальним сховищем, у вас немає резервної копії, якщо щось втрачено на вашій локальній машині. З SVN ви здебільшого працюєте з віддаленим сховищем, яке також є вашим резервним копієм на іншому сервері ... Git може працювати так само, але це не було основною метою Linus мати щось на кшталт SVN2. Він був розроблений для розробників ядра Linux та потреб розподіленої системи управління версіями.
Чи краще Git, ніж SVN? Розробники, яким потрібна лише деяка історія версій та механізм резервного копіювання, мають хороший та простий спосіб життя з SVN. Розробники, які часто працюють з гілками, тестують більше версій одночасно або працюють в основному офлайн, можуть скористатися можливостями Git. Існує кілька дуже корисних функцій, таких як зберігання, не знайдене за допомогою SVN, що може полегшити життя. Але з іншого боку не всім людям знадобляться всі можливості. Тож я не бачу мертвих СВН.
Git потребує кращої документації, і повідомлення про помилки має бути кориснішим. Також існуючі корисні інтерфейси користуються лише рідко. На цей раз я знайшов лише 1 GUI для Linux з підтримкою більшості функцій Git (git-cola). Інтеграція Eclipse працює, але її офіційний сайт не опубліковано, і офіційного сайту оновлень немає (лише деякі зовнішні веб-сайти оновлень з періодичними побудовами з магістралі http://www.jgit.org/updates ) Тож найбільш бажаний спосіб використання Git в ці дні - командний рядок.
Ерік Сінк з SourceGear написав ряд статей про відмінності між розподіленими та нерозподіленими системами управління версіями. Він порівнює плюси і мінуси найпопулярніших систем управління версіями. Дуже цікаве читання.
Статті можна знайти на його блозі, www.ericsink.com :
Для людей, які шукають хороший графічний інтерфейс Git, Syntevo SmartGit може бути хорошим рішенням. Власний, але безкоштовний для некомерційного використання, працює на Windows / Mac / Linux і навіть підтримує SVN, використовуючи якийсь міст git-svn.
http://subversion.wandisco.com/component/content/article/1/40.html
Я думаю, що цілком безпечно сказати, що серед розробників SVN Vs. Аргумент Git вирує вже деякий час, кожен має свій погляд на те, що краще. Про це навіть було сказано в питаннях під час нашого Вебінару з питань підриву в 2010 році та далі.
Хайрум Райт, наш директор з відкритих джерел та президент корпорації Subversion, розповідає про відмінності між Subversion і Git разом з іншими системами управління розподіленими версіями (DVCS).
Він також розповідає про майбутні зміни в Subversion, такі як Робоча копія наступного покоління (WC-NG), яка, на його думку, спричинить перетворення багатьох користувачів Git назад до Subversion.
Подивіться його відео та дайте нам знати, що ви думаєте, коментуючи цей блог або публікуючи на наших форумах. Реєстрація проста і займе лише мить!
Зараз Git в Windows досить добре підтримується.
Перевірте GitExtensions = http://code.google.com/p/gitextensions/
і посібник для кращого досвіду Windows Git.
Останнім часом я проживаю в Git land, і мені це подобається для особистих проектів, але я не зміг би переключити робочі проекти на нього ще з Subversion, враховуючи зміни в мисленні, що вимагається від персоналу, без будь-яких нагальних переваг. Більше того, найбільший проект, який ми проводимо вдома, надзвичайно залежить від svn: зовнішні, які, з того, що я бачив до цього часу, не працює так добре і безпроблемно в Git.
По-перше, одночасне управління версіями здається простою проблемою. Це зовсім не так. Все одно ...
SVN досить інтуїтивно зрозумілий. Гіт ще гірший. [саркастична спекуляція] Це може бути тому, що розробники, які люблять важкі проблеми, як паралельний контроль версій, не мають великого інтересу до створення хорошого інтерфейсу. [/ саркастично-спекуляційна]
Прихильники SVN вважають, що їм не потрібна розподілена система контролю версій. Я теж думав, що. Але тепер, коли ми використовуємо виключно Git, я віруюча людина. Тепер управління версіями працює для мене І команди / проекту, а не просто працює над проектом. Коли мені потрібна філія, я гілка. Іноді це гілка, яка має відповідну гілку на сервері, а іноді - ні. Не кажучи вже про всі інші переваги, над якими мені доведеться вивчатись (частково завдяки подступному та абсурдному відсутності інтерфейсу користувача, який є сучасною системою управління версіями).
Чому я думаю, що Subversion є кращою за Git (принаймні, для проектів, над якими я працюю), головним чином завдяки її зручності використання та більш простого робочого процесу:
http://www.databasesandlife.com/why-subversion-is-better-than-git/