it-roy-ru.com

Почему я должен использовать контроль версий?

Я читал блог, где писатель сказал это

"Код не существует, если он не зарегистрирован в системе контроля версий. Используйте контроль версий для всего, что вы делаете. Любой контроль версий, SVN, Git, даже CVS, освоите его и используйте".

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

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

Это основная идея или я все понял неправильно?

Если я прав, то это может быть бесполезно, если я:

  • Не заставляйте других людей работать над кодом.
  • Не планируйте позволять другим иметь код.
118
JasonDavis

Вы когда-нибудь:

  • Сделали изменения в коде, поняли, что это было ошибкой и хотели вернуться назад?
  • Потерянный код или была слишком старая резервная копия?
  • Нужно было поддерживать несколько версий продукта?
  • Хотите увидеть разницу между двумя (или более) версиями вашего кода?
  • Хотите доказать, что конкретное изменение сломало или исправило кусок кода?
  • Хотите просмотреть историю какого-то кода?
  • Хотите внести изменения в чужой код?
  • Хотите поделиться своим кодом или позволить другим людям работать над вашим кодом?
  • Хотели посмотреть, сколько работы делается, и где, когда и кем?
  • Хотите поэкспериментировать с новой функцией, не мешая работе кода?

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

Чтобы цитировать друга: цивилизованный инструмент для цивилизованного возраста.

252
si618

Даже если вы работаете в одиночку, вы можете воспользоваться контролем источников. Среди прочего, по этим причинам:

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

  • Вы можете экспериментировать по желанию. Если это не решит проблему, верните ее.

  • Вы можете посмотреть предыдущие версии кода, чтобы узнать, когда и где были обнаружены ошибки. git bisect отлично подходит в этом отношении.

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

  • Вы можете увидеть "что изменилось". Это может звучать просто, но я часто проверяю это. Я очень часто начинаю свой рабочий процесс с одного человека: что я делал вчера?

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

Если вам нужна локальная VCS, вы можете настроить свой собственный сервер Subversion (что я делал в прошлом), но сегодня я бы порекомендовал использовать git. Гораздо проще Просто cd в ваш каталог кода и запустите:

git init

Добро пожаловать в клуб.

55
R. Martinho Fernandes

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

Возможно, вы используете контроль версий прямо сейчас, даже если вы этого не знаете. У вас есть какие-нибудь папки с надписью "XXX Php Code (December)" или "XXX.php.bak.2"? Эти являются формы контроля версий уже. Хорошая система контроля версий позаботится об этом автоматически. Вы сможете откатиться к любому моменту времени (когда у вас есть данные) и увидеть точную копию этих данных.

Кроме того, если вы используете такую ​​систему, как Subversion, и используете удаленное хранилище (например, на своем сервере), у вас будет место для хранения всего кода. Нужна копия вашего кода где-нибудь еще? Нет проблем, просто проверьте это. Сбой жесткого диска дома? Не проблема (по крайней мере, с вашим исходным кодом).

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

18
Robert Venables

Даже работая в одиночку, это когда-нибудь случалось? Вы запускаете свое приложение, и что-то не работает, и вы говорите: "Это сработало вчера, и, клянусь, я не трогал этот класс/метод". Если вы регулярно проверяете код, быстрая версия diff показала бы, что именно изменилось за последний день.

14
Ed Schembor

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

Ваш клиент просит вас реализовать амбициозную модификацию сайта. Это займет пару недель и потребует внесения изменений на многих страницах. Вы приступаете к работе.

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

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

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

Приведенный выше сценарий показывает, что контроль версий может быть отличным инструментом, даже если вы работаете в одиночку.

  • Вы можете использовать ветки для работы над долгосрочными задачами, а затем объединить ветку с основной линией, когда это будет сделано.
  • Вы можете сравнить целые наборы файлов с другими ветками или с предыдущими ревизиями, чтобы увидеть, что отличается.
  • Вы можете отслеживать работу с течением времени (что, кстати, отлично подходит для составления отчетов и выставления счетов).
  • Вы можете восстановить любую ревизию любого файла, основываясь на дате или вехе, которую вы определили.

Для сольной работы рекомендуется Subversion или Git. Любой может свободно отдавать предпочтение одному или другому, но одно из них явно лучше, чем использование какого-либо контроля версий. Хорошими книгами являются " Прагматический контроль версий с использованием Subversion, 2nd Edition " Майка Мейсона или " Прагматический контроль версий с использованием Git " Тревисом Свичегудом.


Оригинальный автор: Билл Карвин

12
Robert Harvey

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

Это похоже на гигантскую кнопку "отменить" вплоть до первой строки кода.

10
gbc

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

Он отслеживает изменения в вашем коде и позволяет вам вернуться к предыдущим версиям. Это позволяет вам экспериментировать со знанием того, что если что-то сломается, вы можете отменить свои изменения.

7
Vincent Ramdhanie

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

5
Cadet Pirx

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

Система управления исходным кодом позволит вам пометить каждый выпущенный вами выпуск, чтобы вы могли вернуться к нему позже, внести исправление (и объединить исправление с новым кодом версии 2) и сделать новый выпуск, не беспокоясь о том, что вы можете случайно доставить что-то, что не готов.

Управление исходным кодом является основной частью современной разработки программного обеспечения. Если вы не используете его (даже для личных проектов, поскольку чем больше у вас опыта, тем лучше), вы делаете что-то не так.

Обычно один из первых вопросов, которые я задаю при прохождении собеседования на работу: "Что вы используете для контроля источников?" Пока только одно место говорит "Ничего", но они планировали исправить это "Реально скоро сейчас ..."

3
forgot my open id login

Контроль версий отлично подходит для проверки предыдущих версий, даже если вы работаете в одиночку. Например, если вы случайно удалили код или файл, вы можете получить его обратно; или вы можете сравнить предыдущие версии, чтобы понять, почему появилась новая ошибка. Также хорошо, если вы работаете в нескольких местах.

Мой личный фаворит - это мерзавец.

3
Peter

Есть несколько причин использовать контроль версий, даже если вы единственный человек, который когда-либо будет касаться кода.

  • Резервное копирование - что делать, если ваш жесткий диск выходит из строя? У вас есть где-нибудь копия?
  • История изменений - В настоящее время вы храните копии кода в разных папках? Контроль версий дает вам возможность отслеживать изменения во времени и легко различать различные ревизии, объединять, откатывать изменения и т.д. С помощью инструментов.
  • ветви - возможность протестировать некоторые изменения, по-прежнему отслеживать, что вы делаете, а затем решить, хотите ли вы сохранить его и объединить с основным проектом или просто выбросить.

Если вы держите свой код под контролем версий, тогда вам будет действительно легко увидеть, какие файлы вы изменили (или забыли добавить в базовую линию).

3
Mads Hansen

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

Вы можете быть единственным разработчиком, но все равно выиграете от:

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

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

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

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

2
Vinko Vrsalovic

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

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

Что касается меня, я больше не храню файлы или папки с именем "project_old", когда решаю что-то реорганизовать. Любые изменения, которые я делаю, сохраняются постепенно, и я всегда буду в состоянии вернуться назад к проекту, который работал в целом. Я редко использую FTP для развертывания сейчас, потому что я просто извлекаю код через ssh. Загружаются только файлы, которые я изменил, и если мне нужно перезагрузить сервер, терминал уже там.

Я нашел этот разговор о GIT действительно поучительным; http://www.youtube.com/watch?v=4XpnKHJAok8

Это гугл-лекция, в которой Линус Торвальдс приводит аргумент в пользу использования одной системы контроля версий над другой. При этом он объясняет, как они работают, используя концепции, а затем сравнивает различные способы их реализации.

1
deau

Это также резервное копирование старого файла, поэтому он называется "Subversion". Таким образом, вы можете управлять несколькими версиями своей работы, в которых вы можете вернуться назад (вернуться) и управлять различными ее реализациями (ветвления).

1
NawaMan

Вы можете обнаружить, что у вас была рабочая версия вашей программы.

Вы решаете добавить несколько новых функций в течение определенного периода времени, и вы отпускаете это.

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

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

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

1
James Black

Похоже, вы ищете что-то более легкое. Проверьте Mercurial ( потрясающий справочник ). Я использую это для всего, от исходного кода до личной переписки.

Некоторые преимущества:

  • Кнопка Giant Undo, так что вы можете вернуть те безмятежные дни прошлой недели, когда код действительно работал
  • Выкидной код. Не уверен, что это лучший способ что-то сделать? Сделайте ветку и экспериментируйте. Никто, кроме вас, никогда не должен знать об этом, если вы используете DVCS, как Mercurial.
  • Синхронизированное развитие. Я разрабатываю на 4 разных компьютерах. Я толкаю их между собой, чтобы сохранить текущее состояние, поэтому независимо от того, на каком я нахожусь, у меня есть самые новые версии.
1
Jonathanb

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

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

1
Otto Allmendinger

Вы, вероятно, захотите что-то вроде Subversion, даже если вы работаете самостоятельно, чтобы у вас была история всех ваших изменений. Возможно, вы захотите увидеть, как однажды выглядел фрагмент кода, чтобы вспомнить, почему вы внесли изменения.

Наличие контроля источника также полезно при частой регистрации. Если вы часто регистрируетесь, вы всегда будете в состоянии откатываться слишком часто. Много раз вы могли начать идти по одному пути, чтобы решить проблему, а затем понять, что это был неправильный путь. Много раз вы могли просто продолжать лаять по неверному пути и в конечном итоге создать ужасное решение - только потому, что вы не хотели потерять всю свою работу. Часто проверяя, последний пункт "счастья" не далеко, так что даже если вы идете по неверному пути, вы всегда можете откатиться назад и попробовать еще раз, чтобы найти более элегантное и простое решение. Это всегда хорошо, так что вы можете понять и сохранить то, что вы написали в будущем.

0
digiarnie

Это зависит от размера проекта и от того, как часто вы передумали о его части. Для небольших проектов, в которых вы просто что-то делаете линейно, контроль версий, вероятно, не очень поможет (хотя, если вы случайно удалите или повредите файл без контроля версий, вы будете плакать).

Но пару недель назад я встретил друга, который сам писал огромный хобби-проект. У него было десять или двадцать копий его кода с суффиксами, такими как "X1", "X2", "тест", "быстрее" и так далее.

Если вы сделали более двух копий своего кода, вам требуется контроль версий. Хорошая система контроля версий позволяет вам отменить изменения, которые вы сделали некоторое время назад, не отменяя того, что вы сделали после этого изменения. Это позволяет увидеть, когда были сделаны определенные изменения. Он позволяет вам разбить ваш код на два "пути" (например, один для проверки новой идеи, другой для обеспечения безопасности вашего "проверенного и надежного" кода до завершения тестирования), а затем объединить их вместе.

0
Artelius