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

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

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

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

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

Это основная идея или я ошибаюсь?

Если я прав, то от этого будет мало толку, если я:

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

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

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

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

Неправильно цитирую друга: цивилизованный инструмент для цивилизованной эпохи.

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

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

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

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

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

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

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

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

git init

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это похоже на гигантскую кнопку «отменить», возвращающуюся к вашей первой строке кода.

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

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

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

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

Мой личный фаворит - git.

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

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

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

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

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

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

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

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

Вы можете быть единственным разработчиком, но при этом получите следующие преимущества:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас 2019 год. В этот относительно поздний срок я сталкиваюсь с возражениями против использования Git; Возражения, я вижу здесь некоторые возражения. Это обсуждение в значительной степени прояснило необходимость использования системы контроля версий, а не просто создания именованных резервных копий. Одним из ключевых моментов является использование системы контроля версий даже там, где у нас есть отдельные проекты разработчиков. Никто не идеален. Вы делаете ошибки. Если вы исключительно хороши и умны, вы будете разрабатывать более сложные приложения; но вы все равно будете совершать некоторые ошибки, и это исправит их. Боже, Пит! Я никогда не использую Linux, но думаю, мы все уважаем выдающийся технический интеллект Линуса Торвальдса. Он осознал важность контроля версий и внес ключевой вклад в создание Git. Это обобщающий момент по всем причинам, приведенным здесь. Торвальдс понимает: контроль версий очень важен: использовать систему контроля версий. Спасибо всем, кто прокомментировал эту давнюю тему.