git vs Subversion - плюси і мінуси [закрито]

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

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

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

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

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

Дякуємо, що пролили ще трохи світла на цю проблему.

Чи намагаєтесь ви порівняти два інструменти від сприйняття системного адміністратора чи як програміста? Якщо ви дивитесь на це з точки зору програмістів, можливо, ви повинні запитати це в stackoverflow. А ще краще, можливо, варто поглянути на те, що вже просили про " git svn ".

• /programming/871/why-is-git-better-than-subversion
• /programming/161541/svn-vs-git
• /programming/536779/git-or-svn-for-rails-app
• /programming/1239577/git-and-svn-on-windows
• /programming/1310572/what-are-pros-and-cons-of-using-git-svn

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

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

Доступ контролюється або обліковими записами користувачів / груп на сервері git (для ідентифікації дозволів потрібно правильно ініціалізувати початковий сховище "git init --bare --shared"), або за допомогою клавіш ssh. Дуже детальний контроль доступу може бути налаштований за допомогою "gitosis", який є стороннім адоном.

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

Якщо вам потрібен великий посібник, ознайомтеся з http://progit.org - це повна онлайн-копія книги з відкритим кодом.

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

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

Ми намагалися не поєднувати сховища svn та git, починаючи мігрувати наші незначні сайти та створювати нові сховища git для основних сайтів, як-от нову версію. Доступ керується ключами ssh. Також ми використовуємо gitweb як веб-інтерфейс (наша svn система базується на http)

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