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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

git init

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

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

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

Ответ 6

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

Как будто у вас есть гигантская кнопка "отменить", вплоть до первой строки кода.

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

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

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

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

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

Ответ 13

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

Ответ 14

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

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

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

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

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

Ответ 15

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

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

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

Ответ 16

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

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

Ответ 17

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

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

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

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

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

Ответ 18

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

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

Ответ 19

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

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

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

Ответ 20

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