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

Question

Я работаю над проектом:

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

Какие преимущества я получу от настройки git-репозитория (или чего-то еще) для моего проекта?

Answer 1

В дополнение к уже перечисленным

• дает вам метрики (вы можете увидеть, сколько совершенных вами коммитов, когда и даже по какой причине)
• comments - дает вам еще одно место для документирования и организации вашего кода, что, в свою очередь, дает вам новые способы управления вашим кодом
• memory - вы можете отслеживать именно то, что выизменилось, когда вы исправляли такую-то проблему (у вас есть полный трекбек)

Answer 2

Множество веских причин, почему делать это в других ответах.Лично мне нравится знать, что я могу оглянуться назад на код, который «раньше работал, прежде чем я пытался исправить эту ошибку»;ситуация, которая встречается гораздо чаще, чем хотелось бы.

Для моих личных нужд я обнаружил, что ископаемое - хороший выбор.Он распространяется, не требует много церемоний, устанавливается как один исполняемый файл и доступен для Windows, Mac и Linux «из коробки» и является переносимым.Он предоставляет вики и отслеживание билетов в дополнение к контролю версий.Он имеет встроенный веб-сервер, который используется вместе с вашим браузером для предоставления графического интерфейса пользователя для задач управления и полезен для клонирования и обновлений ad-hoc.Он легко интегрируется с веб-хостингом.Его домашний сайт обслуживается, например, копией окаменелости.

Answer 3

Также ознакомьтесь с Kiln и Fogbugz (которые работают в сочетании с Mercurial). Они предлагают бесплатные аккаунты студентам или командам из одного или двух человек. http://www.fogcreek.com/

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

Ну, в целом, я думаю, что это чрезвычайно полезно, а Kiln и Fogbugz очень легко / быстро настроить.

Ключевым моментом является то, что объединение ветвей работает лучше в распределенных системах контроля версий, таких как Mercurial или Github. Так что, если у вас есть хорошая часть вашего текущего проекта, и у вас есть действительно дикая идея, вы можете выполнить ее, и когда идея действительно сработает, объединение ее сработает очень хорошо. И поскольку слияние работает, пока вы не обнаружите, что ваша дикая идея работает, вы тем временем можете добавлять другие функции и исправления в ствол.

Функции комментирования / обзора Kiln, синхронизированные с вашими версиями, по-моему, имеют смысл и для одного человека. Я знаю, что должен напомнить себе о необходимых улучшениях в какой-то части, или пересмотреть что-то, или я забуду.

Этот пакет действительно хорошо интегрирован и стоит попробовать, у них есть хорошие и краткие описания концепций на их сайте.

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

Answer 4

1) После настройки системы контроля версий ваша жизнь станет намного проще. Резервное копирование изменений источника вручную? О человек, пожалуйста, нет. Что за пита.

С установленным контролем версий вы просто запускаете команду. Он отслеживает изменения и упрощает их сохранение.

Почему вы хотите наказать себя, вручную управляя контролем версий? Использовать git для отслеживания локальных изменений ТАК легко. Легко настроить также.

2) Отслеживание истории. Ведение истории коммитов вручную почти сразу выйдет из-под контроля.

Answer 5

Для того, чтобы сыграть роль адвоката дьявола, я думаю, что Distributed Revision Control более полезен, чем простая централизованная система контроля версий.

Для отдельного разработчика распределенные инструменты почти всегда намного быстрее, чем централизованные инструменты. Это по простой причине: централизованный инструмент должен общаться по сети для многих общих операций, потому что большинство метаданных хранятся в единственном экземпляре на центральном сервере. Распределенный инструмент хранит все свои метаданные локально. При прочих равных условиях общение по сети увеличивает нагрузку на централизованный инструмент. Не стоит недооценивать ценность быстро реагирующего инструмента: вы будете тратить много времени на взаимодействие с программным обеспечением для контроля версий.

Распределенные инструменты безразличны к капризам вашей серверной инфраструктуры, опять же, потому что они копируют метаданные во многих местах. Если вы используете централизованную систему и ваш сервер загорелся, вам лучше надеяться, что ваш носитель резервного копирования надежен, и что ваша последняя резервная копия была последней и действительно работала. Благодаря распределенному инструменту у вас есть множество резервных копий на компьютере каждого участника.

Надежность вашей сети будет влиять на распределенные инструменты гораздо меньше, чем на централизованные инструменты. Вы даже не можете использовать централизованный инструмент без сетевого подключения, за исключением нескольких сильно ограниченных команд. С помощью распределенного инструмента, если ваше сетевое соединение обрывается во время работы, вы можете даже не заметить.

Answer 6

Metadata.Вы можете пометить и прокомментировать проверки.Несмотря на то, что я работаю в командной среде, я часто использую это, чтобы поддерживать ход мыслей и / или отслеживать выполненные задания.