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

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

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

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

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

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

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

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

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

git init

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

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

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

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

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

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

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

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

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

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

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

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

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

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

автор: Билл Karwin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

преимущества:

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

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

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

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

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

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

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

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

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

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

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

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

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