Контроль версій для незалежних розробників?

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

Якщо ви використовуєте децентралізований контроль над джерелами (Mercurial, Git, Bazaar чи будь-який інший), ви отримуєте переваги перед SVN / CVS, що робить його легким, корисним та потужним у використанні у випадку, якщо ви є інді:

1. Ви здійснюєте місцеве рішення : ваш проект проекту - це ваше репо з ПОВНОЮ історією. Таким чином, вам не потрібно мати сервер, ви здійснюєте пряме виконання у вашому репо, і ви можете мати кілька репостів на одному комп’ютері. Використовуючи ноутбук, який ви іноді відкриваєте, щоб продовжувати працювати над своїми речами? Чудово! Вам не потрібно налаштовувати сервер, і якщо він вам знадобиться пізніше, це легко, і ви просто «натискаєте» та «тягнете» зміни між сховищами.
2. Створено для полегшення експериментів : часто потрібно мати уявлення про функцію, не забруднюючи код. За допомогою SVN та CVS ви вже можете використовувати систему розгалуження та викопати гілку, якщо функція не така хороша, як ви хотіли б. Але якщо ви хочете об'єднати функцію з версією багажника, вам доведеться багато важко виправити сюрпризи. Git, Mercurial і Bazaar (принаймні) робить злиття та гілки справді легкими. Ви навіть можете просто дублювати репо, працювати над ним деякий час, все-таки здійснювати і вбивати його або, якщо хочете, внести зміни в основне репо.
3. Гнучкість організації : як було зазначено раніше, коли у вас є репозиції, які ви організовуєте так, як вам потрібно, легко почати самостійно і дозволити іншим людям працювати з вами, змінивши вашу організацію. Жодна організація не нав'язується, так що вам просто доведеться її створити і voilà. Я часто просто натискаю / перетягую зміни між власними комп’ютерами (ноутбук / настільний / сервер) і все ще один на своїх розробниках. Я використовую Mercurial, і це допомагає мені дублювати свою роботу, але також працюю над функціями, про які я думав зовні на своєму ноутбуці, а потім продовжую працювати над іншими функціями на робочому столі, а потім натискаю зміни мого ноутбука на робочому столі або сервері і об'єдную весь робочий стіл + ноутбук і помістіть його (як резервне копіювання та майбутня репо-командна робота) на моєму сервері.
4. Це допомагає налаштувати резервні копії : якщо ви встановите центральне репо (на GitHub, якщо воно є загальнодоступним, або в приватному репо в BitBucket), ви можете легко написати сценарій, який буде виконуватися щоразу після завантаження комп'ютера, а потім передати вказаний сценарій на своїм друзям, щоб вони регулярно створювали резервні копії вашої роботи. Це я зараз роблю, я впевнений, що втратити роботу не буде легко.

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

Контроль вихідного коду вкрай марний для незалежних розробників, оскільки, як ми всі знаємо:

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

Називайте мене "залежним розробником": репозиторії Mercurial легко клонуються між моїм робочим столом, ноутбуками, накопичувачами резервного копіювання USB та bitbucket.org. Я став залежним, і мені це подобається!

Чому ні?

Я соло-розробник і використовую BitBucket і Mercurial для своїх особистих проектів. Можливість повернути та розправити свій код - це занадто добре, щоб передати його.

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

Так. Це дуже дуже корисно. Мій друг Метт Галлахер лише кілька днів тому опублікував цю чудову статтю на цю тему у своєму блозі про розробку iOS / MacOS "Какао з любов'ю".

Стаття орієнтована на Mac & Git, але вона охоплює основи.

Можливо, вас також зацікавлять наступні питання StackExchange (та їх відповіді).

• Чи є переваги використання dvcs для соло-розробника?
• Які методи інструментів можуть принести користь розробнику соло?
• Гіт для сольного розробника.

Варто ?? Обов’язково! Якщо ви не використовуєте Контроль над джерелами, то ви не контролюєте джерела, і це погано. Ви не можете відрізнятись, не можете повернутись, ви не можете відстежувати зміни - ви витратите години, намагаючись дізнатись манекенського помилку, який ви щойно ввели. Краще мати його на якомусь резервному сервері, але ви також можете встановити комп'ютер і використовувати будь-який метод резервного копіювання, який ви вважаєте за потрібне.

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

Так.

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