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

123

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

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

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

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

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

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

  • Не позволяйте другим людям работать над кодом.
  • Не планируйте оставлять код другим.
JasonDavis
источник
4
Вы имеете в виду, что читали "ужасающий код" ...
Джейсон
53
Это странное явление, что многие разработчики (обычно на начальном этапе своей карьеры) придерживаются этой точки зрения, и только когда вы заставляете их использовать систему управления версиями, преимущества начинают расплываться в их головах.
транжира
4
Поднимите руки, кто не разделяет стыда Мартиньо. :)
spender
4
Кто-то покажет @TimEckel деление пополам, где система контроля версий волшебным образом указывает вам на трехстрочное изменение, произошедшее три месяца назад, и говорит, что «здесь была обнаружена ошибка». Ум = взорван.
Джонатан Хартли
5
@TimEckel, вы все еще используете контроль версий, другой тип с меньшим количеством функций.
Abhinav Gauniyal

Ответы:

261

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

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

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

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

si618
источник
20
Этот парень это прибил. Даже когда я работаю над проектами в одиночку, я предпочитаю иметь работающий контроль версий. Полнофункциональная демоверсия Perforce для 2 пользователей отлично подходит для этого.
Almo
3
звучит полезно ... пока мне не придется выучить и овладеть им. heh
potasmic
7
Хорошие моменты. Однако учтите, что контроль версий - это не резервная копия! Резервная копия хранится на отдельной системе / носителе и некоторое время хранит старые резервные копии (на случай, если ваш репозиторий каким-то образом испортится).
sleske
1
Не могу согласиться больше слеске. Вот почему наряду с нашим стандартным резервным копированием виртуальных машин и еженощной проверкой репозитория у меня есть зеркальный репозиторий, который синхронизируется ежечасно, а также выполняется резервное копирование и проверка :) Мы используем Subversion и пришли к выводу, что svnedge - хороший продукт.
si618
7
Привет, Тим, как ты отслеживаешь историю изменений? Как связать историю изменений с системой отслеживания проблем или примечаниями к выпуску? Как вам удается объединять разные ветки кода? Как вы находите изменения, внесенные вами в последние 100 версий? Может быть, если вы программируете в одиночку или никогда не беспокоитесь о том, почему вы изменили код, тогда, возможно, будет достаточно просто резервной копии, но держу пари, как только вы воспользуетесь достойной VCS, вы поймете, почему так много людей используют их.
si618
56

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

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

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

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

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

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

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

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

git init

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

Р. Мартиньо Фернандес
источник
звучит хорошо, поэтому он может быть локальным и не обязательно должен быть в Интернете, чтобы его могли увидеть все? Я использую php-дизайнер, мне он нравится, и у него есть интеграция с Tortoise SVN, не уверен, что это хороший
вариант
1
просто используйте что угодно для начала - затем через некоторое время, когда вы немного узнаете, прочтите альтернативы и попробуйте один из них, затем другой и так далее
ИНФОРМАЦИЯ 1800
5
+1 за пулю о том, что код никогда не комментируется
Эд Шембор
2
@jasondavis в ответ на ваши конкретные вопросы (хотя вы, вероятно, уже знаете), вы можете использовать любую распределенную VCS (git, mercurial и т. д.) локально, без сервера. Вы также можете использовать централизованную VCS (CVS, SVN и т. Д.) Локально, но это было бы гораздо более утомительно для настройки и не принесло бы большой пользы. Независимо от того, какую VCS вы используете, вы можете разместить ее на сервере и по-прежнему не использовать ее в открытом доступе (полезно для передачи данных между компьютерами и предоставления другой резервной копии) - выполните поиск по запросу «частный репозиторий». Вы не можете использовать TortoiseSVN с git, но есть Tortoise-Git.
naught101 05
18

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

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

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

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

Роберт Венейблс
источник
16
... или «Копия копии копии MyWork»
спонсор
1
@spender: Именно это я помню из темных дней до того, как я начал использовать контроль версий :-)
Роберт Венейблс
Это действительно звучит очень полезно, и мой текущий проект несколько велик, по крайней мере, 150-200 файлов, как это работает, я слышу "версия", что означает версия 1 и версия 2, если число увеличивается, что, если я изменяю 1 файл, а не остальные, у меня будет 200 копий неизмененного кода или только копии измененного файла?
JasonDavis
1
Сохраняется только дельта ваших изменений, поэтому, если вы измените одну строку в одном файле, это все, что будет сохранено в этой версии. Файл в системе управления версиями можно рассматривать как сумму всех его изменений,
спонсор
1
Я путешествовал во времени, чтобы исправить приведенный выше комментарий: контроль версий не обязательно хранит только дельту, но он представляет версию как дельту.
henrebotha
14

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

Эд Шембор
источник
Или я просто беру последнюю версию из своих резервных копий, которые создаются каждый раз, когда я сохраняю файл.
Тим Экель,
@TimEckel и некоторые другие люди просто отменяют свои изменения :)
Abhinav Gauniyal
13

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

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

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

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

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

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

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

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


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

Роберт Харви
источник
10

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

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

GBC
источник
7

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

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

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

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


источник
3

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

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

Питер
источник
3

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

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

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

Мадс Хансен
источник
3

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

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

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

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


источник
2

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

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

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

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

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

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

Винко Врсалович
источник
1

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

NawaMan
источник
1

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

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

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

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

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

Джеймс Блэк
источник
1

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

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

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

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

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

Отто Аллмендингер
источник
1

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

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

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

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

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

Deau
источник
Но что, если вы что-то сломаете между коммитами? Тогда ты заблудился. При использовании автоматического управления версиями у вас никогда не возникает этой проблемы, которая возникает при использовании бесполезных служб управления версиями, таких как GitHub и им подобных.
Тим Экель,
1
@TimEckel, что вы имеете в виду, говоря «сломать что-то ч / б коммит»? Если я напишу что-то после последней фиксации и зафиксирую новые изменения с нерабочим кодом, я просто верну свои изменения к последней фиксации. Так просто, как, что.
Abhinav Gauniyal
@TimEckel сказать, что GitHub бесполезен, все равно что сказать, что Linux бесполезен - миллионы не согласятся с вами, но вы все равно говорите это, потому что вы явно умнее этих миллионов, верно?
Charleh
1
@Charleh то, что им пользуются миллионы, не значит, что это хорошо. Миллионы до сих пор пользуются AOL и имеют альбомы Бритни Спирс. Я использую GitHub каждый день и ненавижу его каждый раз. Я не вижу в этом необходимости, это мешает и тормозит.
Тим Экель
0

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

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

digiarnie
источник
0

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

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

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

Artelius
источник
-2

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

JPDura
источник