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

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

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

Чи є плюси і мінуси обох підходів?

Ні

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

Почніть з Git знизу вгору та йдіть звідти.

Контраст стандартної централізованої системи оновлення / фіксації моделей з Git - це порівняння шини з масовим транспортом. Автобус доставить вас (і всіх інших) з точки А до точки В, використовуючи абсолютно той самий маршрут. Масовий транзит доставить вас з пункту А в пункт В, використовуючи будь-який маршрут, який вам подобається.

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

Ревізія хешей проти чисел

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

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

З Git у всіх однакові хеши. У різних сховищах немає різної кількості комісій, і всі знаходяться на одній сторінці. З Hg це менше. На практиці, якщо вам доведеться підтягувати хеші фіксації та працювати з ними (для порівняння чи переходу часової шкали коду), легше синхронізуватись з іншими людьми, коли у вас є хеші замість чисел.

Ні, будь ласка, навіть не турбуй.

Серйозно, почніть з DVCS. Той факт, що SVN популярний, не робить його стандартом. Лінус Торвальдс сказав би вам, що це може гнити ваш мозок .

Прочитайте цю чудову статтю / вступ Джоела Спольського під назвою Subversion Re-Education .

Можливо, вам також буде цікаво прочитати це інше запитання: Я підривник, чому я повинен вважати чи не вважати Mercurial або Git чи будь-яким іншим DVCS?

Вибір між DVCS

Особисто я використовую і меркурій, і git, і я вважаю, що важливо знати обоє. Про це рекомендується прочитати Git vs. Mercurial: Будь ласка, розслабтеся (див. Приклад git-addremove). Дві цитати з цієї статті, які, на мою думку, підсумовують її.

Щодо git:

Філософія дизайну Git безперечно є філософією Unix: на відміну від Subversion, CVS або Mercurial, git - це не один монолітний бінарний, а безліч індивідуальних інструментів, починаючи від команд високого рівня «фарфор», таких як git-pull, git-merge та git-checkout на низькорівневі “сантехнічні” команди, такі як git-apply, git-hash-object та git-merge-file. Отже, як і MacGyver, ви можете робити майже все, що вам потрібно з Git - це включає в себе абсолютно приголомшливі двигуни Wiki, видавати трекери, файлові системи, інструменти sysadmin - все, що не має відновлення запобіжників.

Що стосується ртутних:

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

Дуже багато проектів можна знайти на github, і git є більш потужним, але він також може дещо залякати новачків, особливо користувачів Windows. Існує також бітбукет (еквівалент github для mercurial).

Моя рекомендація: починайте з меркуріалу, і як тільки вам буде комфортно з цим, підберіть git; мова не про інструменти, а про людей, з якими ви працюєте .

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

• Наразі svn майже встановлений у більшості хостинг-провайдерів
• Має гарну підтримку підпроекту (хоч адресується в git та hg зараз). svn upі ваш проект та його залежності оновлюються.

Цитуючи Thorbjørn на цій іншій темі :

DVCS - це Subversion, що Bittorrent - ftp

Редагувати : Якщо є VCS, вам слід знати, перш ніж Git, це може бути Mercurial (набагато привітніший інтерфейс CLI і добре познайомитись з розподіленими поняттями). Ця порада спеціально стосується тих, хто походить із Subversion, оскільки CLI також певною мірою схожий. Розподілений контроль над версіями може бути легшим для вивчення, ніж централізований контроль версій, оскільки ви просто турбуєтесь про свій екземпляр сховища, а не про клієнтські та серверні частини окремо .

Ви повинні вивчити, що ви маєте намір використовувати. Git популярний, так само як Mercurial також користувався певною популярністю. Git / Mercurial - це системи управління розподіленими джерелами.

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

• Яка мета контролю версій в нашій команді. Так, усі системи управління версіями, що варті нічого, дозволять вам повернутися в історію та побачити, що змінилося в будь-якому файлі. Однак чи збираєтесь ви використовувати його для створення нових версій? (киває головою, ти цього хочеш). Це 2-3 рядкове бачення для того, що ви хочете досягти.
• Чи звикла ваша команда мати власне місцеве робоче середовище лише для того, щоб потім обережно об'єднати речі? Якщо так, маршрут DVCS може мати найбільш сенс.
• І навпаки, ваша команда звикла працювати з одного спільного накопичувача, і все в постійній інтеграції? Якщо так, то традиційний VCS може мати найбільше сенсу.

Оцінюючи Ваші альтернативи, Ви повинні враховувати важливі речі, які необхідно зробити:

• Базовий код (позначені гілки, мітки тощо). В основному, як отримати точний вихідний код, використаний у випуску вашого проекту.
• Отримайте локальні зміни на центральному сервері. Потрібно мати авторитетну копію коду - ви використовуєте DVCS або стандартний VCS. Кожен інструмент трактує цей процес по-різному.
• Отримайте зміни на центральному сервері до локальної копії.
• Як боротися з експериментальними змінами. VCS дозволяють бути більш сміливими із запропонованими змінами, не порушуючи основний вихідний код проекту. DVCS та стандартні системи VCS підходять до цього зовсім по-різному - одна з них буде найкраще працювати для вашої команди.
• Як налаштувати та налаштувати сервери?
• Вам потрібна автентифікація? Якщо так, то як ви переконаєтесь, що насправді можуть лише ті люди, яким дозволено вносити зміни?

Зрештою, зробіть швидку оцінку, щоб визначити, чи стандартні системи VCS або DVCS будуть найкращі для вашої команди. Вам доведеться вибрати той інструмент, який надає найменшу кількість болю, інакше він, швидше за все, не буде прийнятий. Після цього оцініть свої альтернативи, які найкраще відповідають вашим потребам.

Зрештою, дізнайтеся, що ви маєте намір використовувати.

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

Хоча git є моїм кращим VCS, я б сказав, що, мабуть, найкраще також вивчити підрив. Для одного, є ще багато підривних та сховищ резюме, що вам, можливо, доведеться взаємодіяти з одним днем, а також ви матимете краще розуміння точних переваг та недоліків DVCS перед традиційними VCS.

Було б контрпродуктивно вивчати svn, а потім git

Ось кілька причин:

• Гетс кардинально відрізняється від svn. Невдоволений Git і svn - клієнт / сервер.
• До одних і тих же слів додаються різні значення. Наприклад, "git checkout ..." має інше значення, ніж "svn checkout ..."
• Відгалуження буває різним. Git має таке поняття «тематичні» гілки, які є дешевими місцевими гілками, які svn не підтримує.
• У Git є додаткове місце, зване індексом, яке знаходиться між робочим деревом та вашим сховищем. Svn не має індексу. За допомогою git ваші зміни переміщуються з вашого робочого дерева в індекс до сховища.

Моя порада - просто вивчити git.

У GIT та SVN деякі речі широко однакові, а деякі - ні.

Створити / оновити / оформити / здійснити

Загалом же, ви повинні забрати його легко.

як тегувати і розгалужувати, але все ще багато бентежить щодо конфліктів між гілками та стовбуром тощо

Різні між ними.

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

Ого; 12 відповідей, і всі все ще просять питання ...

Ні, Subversion не є необхідною умовою для Git.

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

• svn commitінша річ, ніж git commit.
• гілки в svn і git дуже різні
• сховище svn більше схоже на віддалений git (але насправді)
• сховище git більше схоже на робочу копію svn (але насправді)

Це два інструменти, розділені загальною мовою.

Ваше запитання та більшість інших відповідей припускають, що git - це якась svn ++; "Кращий svn". Це не так. Два - це різні інструменти, які працюють в одному просторі, як машина та мотоцикл.

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

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

Напевно, ні - між серверними та розподіленими є достатньо відмінностей, які ви, мабуть, лише плутаєте себе далі.

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

Подивіться на Mercurial (якщо ви не хочете, щоб вас перебили).

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

Варто навчитися Git, поки у вас є шанс не знищити розум від Subversion.

Я не думаю, що розуміння Subversion не потрібно для розуміння Git.

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

Мені дуже подобається git в середовищі Unix (Linux, MacOS X). У вікнах це трохи хакі. Я б вважав Меркуріалом, якщо у мене в рівнянні є Windows.

Мені вам сподобалися ваші уроки історії, спробуйте SCCS, RCS, CVS, Subversion, а потім використовуйте щось корисне, як Git або Mercurial.

Git і Mercurial є однопотужними, великим бонусом Git є github . Але якщо ви не хочете передавати аутсорсинг свого контролю версій, github вже не в рівнянні.

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

Ви можете навчитися Git зараз і вкласти час у пізніше, коли вам потрібно.

Ні. Завантажте Git, створіть аккаунт github і поводьтесь протягом декількох днів, розгортаючи репост тощо. Вивчіть 5 або 6 команд bash, і ви зможете виконувати всі найважливіші завдання. Я, як правило, віддаю перевагу "ідіотії" графічного інтерфейсу, але Git Bash - це так просто, як це стає. Крім того, Git Gui є досить пристойним, якщо ви віддаєте перевагу цьому маршруту. Я не дуже бачу користі, яку ви побачили б від вивчення SVN. Я пройшов деякий час назад, коли я оцінював кілька різних систем управління версіями для нового проекту з відкритим кодом. Я спробував SVN, Bazaar, Git та пару інших та навчився азам кожного. YMMV, але Git був на сьогодні найпростішим. З навчанням SVN також немає нічого поганого, але це дійсно не допоможе вам вивчити Git.