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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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