git для особистих проектів. Перевищення?

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

Зараз я використовую Subversion для особистих проектів, тому що я думаю, що Git там мало сенсу. Здається, це трохи непосильне. Для мене це нормально, якщо він є централізованим (зазвичай, на домашньому сервері), коли я єдиний розробник; Я все-таки беру регулярні резервні копії. Мені не потрібно вміння робити власну гілку, головна гілка - моя гілка. Так, SVN має просту підтримку розгалуження, але набагато більш потужна підтримка для цього не має сенсу. Злиття може бути болем з цим, або, принаймні, з мого невеликого досвіду.

Чи є для мене якась вагома причина використовувати git в особистих проектах, чи це просто просто зайвий рівень?

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

Хочете розпочати новий проект?

> git init

БАМ! Не потрібно налаштовувати сервер сховища, ані перевіряти структуру папок для підтримки розгалуження та тегів у сховищі субверсії.

Спільний доступ до вашого проекту пізніше - це лише питання: git push(крім того, щоб мати віддалене сховище). Спробуйте це зробити швидко з підривом!

Я заперечую, що використання Subversion для місцевих особистих проектів є надмірним, тоді як Git, безумовно, ні. Git займе менше місця (через неефективну концепцію "ревізії" SVN порівняно з знімками об'єктів Git), вимагає менших налаштувань ( git initпроти десятка svnadminкоманд та налаштування дозволів тощо), резервні копії простіше ( git clone --bare[або git push originякщо ви використовуєте Github або подібне], і ви готові), і має кращі інструменти для керування кодом (розгалуження безкоштовне, а злиття простіше і чіткіше). Тільки тому, що ніхто більше не має клона вашого сховища, не означає, що переваги будь-яких DVCS є "надмірними".

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

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

Це походить від давнього користувача Subversion. Консолідація за одним інструментом справді може полегшити ваше життя.

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

Я використовую Git для моїх одноосібних проектів і мені це подобається. Раніше я використовував Subversion, і я ще не бачив недоліків використання Git. Це більш потужне, але не таким чином, що ускладнює прості речі. Створення простих речей надмірно складних / дорогих / повільних / тощо. IMHO є необхідною умовою для виклику чогось overkill. Крім того, на Github я замовив раніше проекти інших людей, щоб додати потрібну функцію, а потім надіслав їм запити на те, щоб надіслати їх. Мені було б здорово, якби хтось, хто зацікавився моїми проектами, зробив те саме.

Я ніколи не використовував управління джерелами в особистих проектах перед DVCS, тому дивно уявити, що хтось займає протилежну точку зору. Деякі мої причини:

• Легко налаштувати та руйнувати. Наприклад, минулого тижня колега подарував мені головоломку з програмування, яку я вирішив у кілька невеликих кроків. Я зробив git repo, який тривав усі 45 хвилин, щоб утримати свою роботу, а потім його вже не було. Я не знаю, як легко щось подібне знаходиться в підриві, але я ніколи не чув, щоб хтось це робив.
• Відключено. Для мене можливість працювати в режимі офлайн - це більше користь для хобі-проекту, ніж робота для роботи. Мені не потрібно пробивати дірку в домашньому брандмауері чи публічно розміщувати проект. Я можу тимчасово поставити РЕПО на привід великого пальця або ноутбук і все одно тримати все синхронізовано.
• Все колоковано. Спільне використання репо та робочого дерева полегшує невеликі проекти, які слід відстежувати під час таких речей, як оновлення ОС.
• Потужні функції. Звичайно, мені не потрібна сила постійно, але вона є там, коли мені це потрібно, і не споживає ніяких ресурсів, коли я цього не потребую.

Мені сказали, що git-bisectдуже приємно знаходити точну фіксацію, яка запровадила певну поведінку, переміщуючись туди-сюди в комітетах залежно від вашого вкладу.

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

РЕДАКТУВАННЯ. Крім того, здатність до розгалуження дуже важлива, коли вам доведеться робити виправлення у старих версіях, якими користуються клієнти. Ви повинні вміти керувати "просто виправити цю крихітну річ, але я не хочу найновішої версії, тому що я не хочу перевіряти її знову".

Це залежить від того, наскільки серйозно ви хочете зайнятися версією власного коду. Якщо ви будуєте, наприклад, просту бібліотеку, яка буде мати коли-небудь поточну версію (або настільки довго, наскільки це правда), я особисто використовую базовий варіант резервного копіювання, такий як Dropbox. Якщо ви втратите весь код, можете відновити його з Інтернету, а у Dropbox є резервна копія версії 30 днів, якщо ви дійсно зробите щось дурне.

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

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

Звичайно, більшу частину часу для невеликих особистих проектів ви не будете використовувати більшість функцій, але налаштування сховища git (або навіть локального сховища Subversion) не є великою справою, тому займіться цим! І перш ніж це знати, ви захочете знати "чорт забирай, який був вміст файлу X минулої п’ятниці?". Без контролю версій - удачі ;-)

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

Тільки тому, що про це ніхто не згадував: для особистих проектів Darcs справді хороший і менш задіяний, ніж git для прямого контролю версій. Це не так швидко для більших проектів, але тоді, і це не Subversion!

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

Багато розробників кажуть: "Я просто роблю копії коду". Але цими копіями стає важко керувати і в кінцевому підсумку стає неспокійним. У вас є кілька копій і не можете запам'ятати, яка копія для чого, а потім спробуйте розібратися, коли їх безпечно видалити.

Все це стає ще більш цінним, коли експеримент тягне за собою скоординовані зміни в декількох файлах. А коли це сольний pfoject за допомогою Git стає ще простішим.

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