Я работаю над проектом:
Какие преимущества я получаю от создания репозитория git (или что-то еще) для моего проекта?
История изменений. Зная, какие изменения произошли, когда и как это повлияло на ваш проект. Это также хорошая практика, чтобы быть в привычке. Если вы когда-либо расширяете проект и нуждаетесь в большем количестве людей, чтобы помочь, у вас уже будет хранилище для других людей, с которыми можно работать.
Когда-либо делайте изменения в файле и думайте "Oh sh **..., мне жаль, что я не могу отменить это!".
Вот почему команде разработчиков одного человека по-прежнему требуется управление версиями.
Изменить: я должен уточнить, что управление версиями позволяет вам просматривать изменения в течение всей истории проекта. В большинстве систем вы также можете сравнить бок о бок перед возвратом. Это далеко не просто выбор резервной копии в какой-то момент, ее восстановление и надеемся, что у вас есть файл, который вам нужен.
Как только вы начнете использовать управление версиями (для небольшого проекта, могу ли я рекомендовать простой в установке Bazaar?), ваш вопрос будет отвечать на запросы почти мгновенно, и с ясностью ни одна дискуссионная доска никогда не сможет предоставить:)
Вы говорите, что используете Dropbox для восстановления ошибок (или "может" ), поэтому вы используете Dropbox как ваш контроль версий. Очень простой, плохо разработанный. Dropbox отлично подходит для многих вещей, но это не поможет вам определить, какие файлы были изменены вместе в одно и то же время или вернуть папку в определенный моментальный снимок.
Это то, что "правильный" контроль версий может сделать лучше для вас.
Всегда смотрите на какой-то фрагмент кода и думаете: "Почему я это сделал?" Контроллер источника ответит на это для вас, через отметки времени и комментарии для каждой фиксации.
И если ничего другого, зная, как использовать контроль источника, это ценный навык для разработчика.
Чувство: "Ой, угадайте, я должен был потратить время на это" в собеседовании не весело, особенно на чем-то столь полезном/существенном. Потенциальным работодателям нравится проявлять гибкость и ответственность, даже если ваше резюме кода велико.:)
Я обнаружил, что использование контроля версий (git является моим предпочтением) держит меня дисциплинированным в развертывании партий прогресса в моем коде, и я подозреваю, что это приводит и к другим лучшим практикам.
Я тоже сольный разработчик, и я никогда не делил репо.
Метаданные. Вы можете пометить и прокомментировать проверки. Несмотря на то, что я работаю в командной среде, я часто использую это, чтобы поддерживать свой ход мысли и/или отслеживать элементы, которые я выполнил.
1) После того, как система управления версиями настроена, это сделает вашу жизнь намного проще. Ручная резервная копия изменений вашего источника? О человек, пожалуйста, нет. Что такое ПИТА.
С контролем версий на месте вы просто запускаете команду. Он отслеживает, какие изменения и облегчает их сохранение.
Почему вы хотите наказать себя, вручную управляя контролем версий? Использование git для отслеживания локальных изменений очень просто. Легко настроить также.
2) Отслеживание истории. Сохранение истории транзакций вручную почти сразу выйдет из-под контроля.
Также ознакомьтесь с Kiln и Fogbugz (которые работают в сочетании с Mercurial). Они предлагают бесплатные счета для студентов или команд одного или двух человек. http://www.fogcreek.com/
Когда вы посмотрите на это, вы можете удивиться, почему из всего, что я бы рекомендовал распределенной системе управления версиями для одного разработчика...
Ну, в общем, я думаю, что он очень полезен, а Kiln и Fogbugz очень просто/быстро настроить.
Главное, что слияние веток лучше работает в распределенных системах управления версиями, таких как mercurial или github. Поэтому, если у вас есть хорошая часть вашего текущего проекта, закодированного, и у вас есть действительно дикая идея, вы можете разветкить ее, и когда идея действительно работает, слияние ее обратно работает очень хорошо. И поскольку слияние работает до тех пор, пока вы не найдете свою дикую идею, вы все равно можете добавить другие функции и исправления в туловище тем временем.
Функции комментариев и комментариев Kiln, которые синхронизированы с вашими версиями, также имеют смысл для одного человека. Я знаю, что должен напомнить себе о необходимых улучшениях в какой-то части или о чем-то, или я забуду.
Этот пакет действительно хорошо интегрирован и стоит попробовать, у них есть хорошие и короткие рекламные ролики на концепциях на их сайте.
Если вы думаете, что это слишком много, возможно, так, но я думаю, что дополнительная мощность в этой настройке не будет мешать вам.
Потому что большая часть кода, который вы пишете, неверна. Разумеется, шахта и я считаю чертовски хорошим кодером.
Приятно иметь возможность вернуться к рабочей версии, также вы найдете пользователей (и это может включать в себя себя!) flip flop между "Я хочу все" и "Я просто хочу резюме", это полезно, если вы версия "Я хочу все" безопасно спрятала.
Достаточно веские причины, чтобы сделать это в других ответах. Лично мне нравится знать, что я могу оглянуться назад на код, который "работал, прежде чем я попытался исправить эту ошибку"; ситуация, которая встречается гораздо чаще, чем мне хотелось бы.
Для моих личных нужд я обнаружил, что fossil - хороший выбор. Он распространяется, с низкой церемонией, устанавливается как один исполняемый файл и доступен для Windows, Mac и Linux из коробки и переносится за его пределы. Он обеспечивает вики и отслеживание билетов в дополнение к контролю версий. Он имеет встроенный веб-сервер, используемый вместе с вашим браузером для предоставления графического интерфейса для задач управления и полезный для клонирования и обновлений ad-hoc. Он легко интегрируется с веб-хостом. Например, его домашний сайт обслуживается копией ископаемого.
В дополнение к уже указанным
Я рекомендую использовать bzr, поскольку он лучше всего подходит для тех, кто просто использует его для своего собственного кода (а не для команды), поскольку он не требует резервного копирования на сервер (все ревизии хранятся с каждой "ветвью" )...
Что касается преимущества, то вы можете отменить изменения кода в любой момент времени, поэтому, если вы делаете ежедневные резервные копии, вы можете откатить код, чтобы получить его с любого дня, когда вы сделали резервное копирование. Таким образом, вы можете чувствовать себя комфортно, переписывая код или удаляя старый код, который, по вашему мнению, вам не понадобится, но если вы снова нуждаетесь в нем, он доступен. Для более крупных проектов это помогает при отладке, поскольку, если новая функция делает ошибку, вы можете вернуться к предыдущей, если потребуется.
Вы можете проверить в истории фиксации, как долго мясо находится в духовке. (В случае, если вы совершаете перед приготовлением, когда вы код дома, как и я.)
Чтобы играть в адвоката дьявола, я думаю, что Distributed Revision Control более полезен, чем просто простая система управления версиями, которая является централизованной.
Для отдельного разработчика распределенные инструменты почти всегда намного быстрее, чем централизованные инструменты. Это по простой причине: централизованный инструмент должен говорить по сети для многих общих операций, потому что большинство метаданных хранится в одной копии на центральном сервере. Распределенный инструмент локально сохраняет все свои метаданные. При прочих равных условиях общение по сети добавляет накладные расходы к централизованному инструменту. Не недооценивайте ценность быстрого, отзывчивого инструмента: вы будете тратить много времени на взаимодействие с вашим программным обеспечением для контроля версий.
Распределенные инструменты безразличны к капризам вашей серверной инфраструктуры, опять же потому, что они копируют метаданные во множество мест. Если вы используете централизованную систему, и ваш сервер загорается, вы можете надеяться, что резервные носители будут надежными и что ваша последняя резервная копия была последней и фактически сработала. С помощью распределенного инструмента у вас есть много резервных копий на каждом компьютере-компиляторах.
Надежность вашей сети будет влиять на распределенные инструменты намного меньше, чем централизованные инструменты. Вы даже не можете использовать централизованный инструмент без сетевого подключения, за исключением нескольких сильно ограниченных команд. При использовании распределенного инструмента, если ваше сетевое соединение снижается во время работы, вы можете даже не заметить.