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

Как вы думаете, стоит ли использовать контроль версий, если вы независимый разработчик, и если да, то почему? Вы храните репозиторий на своем компьютере или в другом месте, где он может служить резервной копией?

Если вы используете децентрализованное управление исходным кодом (Mercurial, Git, Bazaar и т. Д.), Вы получаете преимущества по сравнению с SVN / CVS, что делает его легким, полезным и мощным для использования в случае, если вы - инди:

1. Вы фиксируете локально : каталог вашего проекта - это ваш репозиторий с полной историей. Таким образом, вам не нужно иметь сервер, вы делаете коммит прямо в своем репо, и вы можете иметь несколько репо на одном компьютере. Используя ноутбук, который вы открываете иногда, чтобы продолжить работу над своими вещами? Большой! Вам не нужно настраивать сервер, и если он вам понадобится позже, это легко, и вы просто «проталкиваете» и «вытягиваете» изменения между репозиториями.
2. Это сделано для облегчения экспериментов : часто вам нужно иметь представление о функции без загрязнения кода. С SVN и CVS вы уже можете использовать систему ветвления и отбрасывать ветку, если функция не так хороша, как вы хотели. Но если вы хотите объединить эту функцию с внешней версией, у вас будет много неприятных сюрпризов. Git, Mercurial и Bazaar (по крайней мере) делают слияния и ветки действительно легкими. Вы можете даже просто скопировать репо, поработать над ним некоторое время, по-прежнему фиксировать и убивать его или помещать свои изменения в основной репо, если хотите.
3. Гибкость организации : как указывалось ранее, поскольку у вас есть репозитории, которые вы организуете по своему усмотрению, легко начать в одиночку и позволить другим людям работать с вами, изменив вашу организацию. Ни одна организация не навязывается, поэтому вам просто нужно ее настроить и вуаля. Я часто просто проталкиваю изменения между моими собственными компьютерами (ноутбук / рабочий стол / сервер), и я все еще один на своих разработчиках. Я использую Mercurial, и это помогает мне дублировать мою работу, но я также работаю над функциями, о которых я думал снаружи, на моем ноутбуке, затем продолжаю работать над другими функциями на моем рабочем столе, затем помещаю изменения в моем ноутбуке на мой рабочий стол или сервер и объединяю весь рабочий стол + Ноутбук и поставить его (в качестве резервного и будущего командного репо) на моем сервере.
4. Это помогает настроить резервное копирование : если вы настраиваете центральное хранилище (в GitHub, если оно общедоступное, или в частном хранилище в BitBucket), вы можете легко написать сценарий, который будет выполняться при каждой загрузке компьютера, а затем передать указанный сценарий на своим друзьям, чтобы он регулярно делал автоматические резервные копии вашей работы. Это то, чем я занимаюсь, теперь я уверен, что потерять работу будет нелегко.

Фактически, в настоящее время у вас нет оправдания тому, чтобы не использовать инструмент источника управления для какого-либо проекта. Потому что они более мощные и гибкие, чем раньше, и соответствуют вашим потребностям.

контроль исходного кода совершенно бесполезен для независимых разработчиков, потому что, как мы все знаем:

• независимые разработчики никогда не ошибаются
• независимые разработчики никогда не выходят на ревизии, которые не работают
• независимые разработчики никогда не имеют более одной версии, поэтому они не используют ветки
• независимые разработчики никогда не заботятся о том, что они изменили вчера или на прошлой неделе
• независимые разработчики никогда не нуждаются в резервных копиях

Назовите меня «зависимым разработчиком»: репозитории Mercurial легко клонируются между моим рабочим столом, ноутбуками, USB-накопителями и bitbucket.org. Я стал зависимым, и мне это нравится!

Почему нет?

Я сольный разработчик и использую BitBucket и Mercurial для своих личных проектов. Возможность вернуть и обработать ваш код слишком хороша, чтобы от нее отказаться.

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

Да. Это очень очень полезно. Мой друг Мэтт Галлахер опубликовал эту прекрасную статью на эту тему всего несколько дней назад в своем блоге для разработчиков iOS / MacOS «Какао с любовью».

Эта статья ориентирована на Mac & Git, но охватывает основы.

Вас также могут заинтересовать следующие вопросы StackExchange (и ответы на них).

• Есть ли преимущества в использовании dvcs для индивидуального разработчика?
• Какие методы инструментов могут принести пользу одиночному разработчику?
• Git для сольного разработчика.

Стоит?? Должен! Если вы не используете Source Control, то вы не контролируете свои источники, и это плохо. Вы не можете различить, вы не можете вернуться, вы не можете отслеживать изменения - вы потратите часы, пытаясь выяснить фиктивную ошибку, которую вы только что ввели. Лучше иметь его на каком-либо резервном сервере, но вы также можете использовать свой компьютер и использовать любой способ резервного копирования, который сочтете нужным.

Абсолютно используйте источник контроля. Затем настройте сервер сборки и автоматизируйте процессы сборки и тестирования. Триггер строит из ваших исходных коммитов вашего центрального репо. Я работал таким образом три года, и это прекрасно.

Да.

Даже отдельным разработчикам иногда нужно видеть состояние своего кода из прошлой версии. И всегда хорошая идея сделать резервную копию всего важного, и это относится ко всем людям.