Начало работы с контролем версий

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

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

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

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

Выбирайте SVN.

Самое важное в управлении версиями:

ПРОСТО НАЧНИТЕ ИСПОЛЬЗОВАТЬ

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

Конвертировать из

cvs<->svn<->git<->hg

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

Если вы ищете простой в использовании графический интерфейс, посмотрите TortoiseSVN (Windows) и Версии (Mac) (предложено кодирование без комментариев)

Редактировать:

pix0r said:

Git has some nice features, but you won't be able to appreciate them unless you've already used something more standard like CVS or Subversion.

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

Изменить 2:

Только что видел эту ссылку на Reddit: Памятка по Subversion. Хороший краткий справочник по командной строке svn.

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

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

Итак, я просто установил SVN Server и Tortoise SVN для клиента и погрузился в глубину, и я не узнал, как их использовать на этом пути.

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

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

Начните использовать SVN для своей реальной работы, но постарайтесь найти время, чтобы повозиться с Git и / или Mercurial. SVN достаточно стабилен для производства, но в конечном итоге вы столкнетесь со сценарием, когда вы необходимость распределенный SCM, к тому времени вы будете должным образом вооружены, и новые системы станут достаточно зрелыми.

Мой голос отдан Subversion. Он очень мощный, но простой в использовании, и в нем есть отличные инструменты, такие как TortoiseSVN.

Но, как говорили до меня другие, ПРОСТО НАЧНИ ЭТО ИСПОЛЬЗОВАТЬ. Контроль версий - такая важная часть процесса разработки программного обеспечения. Без него не может быть ни одного «серьезного» программного проекта.

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

Да, SVN для предпочтения, если вам действительно не нужны определенные функции git. SVN достаточно сложен; Похоже, что с git жить сложнее. Вы можете получить хостинг svn от таких людей, как Бобовый стебель - если у вас нет штатных специалистов по Linux, я бы очень порекомендовал его. Что-то может ужасно легко пойти не так, и приятно иметь кого-то, чья работа заключается в том, чтобы это исправить.

Есть отличный руководство по контролю версий от Эрика Синка, который стоит прочитать независимо от того, какую систему вы используете.

superjoe30 writes:

Related question (perhaps answers can be edited to answer this question as well):

What about using source control on your own computer, if you're the sole programmer? Is >>this good practice? Are there related tips or tricks?

Я использую SVN для всех своих личных проектов. Я начал с запуска svn на своем домашнем компьютере, но в конце концов перешел на Dreamhost. Их пакеты хостинга, которые включают Subversion, довольно разумны.

Если вы работаете в Mac OSX, я обнаружил, что http://www.versionsapp.com/">Versions представляет собой невероятный (бесплатный) интерфейс с графическим интерфейсом для SVN.

На моей нынешней работе мой предшественник не использовал никакого контроля версий. Есть просто горы папок как минимум в 3 разных местах, где он хранил все свои проекты. Можно ожидать, что любая случайная папка проекта найдет по крайней мере одну папку с именем «проект (СТАРЫЙ)» и одну с именем «проект».

Благодаря контролю версий вам никогда не придется делать копии «безопасных» сборок. Вам действительно не нужно беспокоиться о том, что ваша IDE повредит файл, над которым вы работаете (я смотрю на вас, REALBasic 5.5), потому что так легко фиксировать (читать: сохранять) вашу работу каждый день.

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

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

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

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

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

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

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

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

Я использовал RCS, CVS, SCCS, SourceSafe, Vault, perforce, subversion и git.

Я оценил BitKeeper, Dimensions, arch, bazaar, svk, ClearCase, PVCS и Synergy.

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

Это бесплатно, быстро и активно разрабатывается.

И вы можете использовать его как клиент любого репозитория Subversion с помощью git-svn.

Это круто.

@superjoe30

What about using source control on your own computer, if you're the sole programmer? Is this good practice? Are there related tips or tricks?

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

5-секундное вступление (при условии, что вы его установили)

cd myproject
git init
git add * # add all the files
git commit

В следующий раз, когда вы сделаете некоторые изменения

git add newfile1 newfile2 # if you've made any new files since last time
git commit -a

Пока вы это делаете, git будет вам спиной. Если вы ошиблись, ваш код будет в безопасности в хорошем репозитории git. Это круто

• Примечание: вам может показаться, что вытащить что-то из git немного сложнее, чем вставить его, но гораздо предпочтительнее иметь эту проблему, чем не иметь файлов вообще!

Если вы новичок в управлении версиями, прочтите это:
Source Control HOWTO

Я определенно предпочел бы SVN CVS, хотя бы потому, что люди, которые изучили систему управления версиями с помощью CVS, склонны использовать «svn delete», а затем «svn add» вместо «svn move». Это затрудняет поиск всех предыдущих версий конкретного файла. И вы всегда можете перейти на использование git-svn. Я лично считаю, что его легче изучить, чем hg, но на самом деле причина использования SVN для главный заключается в том, что он в значительной степени стал де-факто системой контроля версий программного обеспечения с открытым исходным кодом.

Если вы когда-нибудь планируете изучать / использовать D, почти обязательно получить доступ к сторонним репозиториям, таким как DSource.

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

@Orion Edwards Subversion не требует сервера. Вы можете получить доступ к локальному репозиторию напрямую (через клиента, конечно), при этом серверный процесс не задействован.

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

Да, бывает.

Как уже много раз упоминалось в другом месте, Just Do It. Я быстро смог начать работу с Subversion под Windows с нуля, прочитав краткое руководство в Красной книге. Как только я указал TortoiseSVN на репозиторий, я занялся бизнесом. Мне потребовалось время, чтобы убрать более тонкие моменты, но это были незначительные неровности, которые нужно было преодолеть.

Я бы предложил установить службу Subversion вместо использования URL-адресов file: //, но это в основном личные предпочтения. Для репозитория, хранящегося на вашем компьютере разработчика, file: // работает нормально.

Git превосходит Subversion, но он немного не на высоте.

Я бы сказал, если вы только начинаете, прыгайте на край; создать бесплатную учетную запись @ http://github.com

У них есть учебные материалы по настройке и использованию git.

Используйте TortoiseSVN (version.app на Mac). Просто установите и работайте. Если вам нужно место для размещения вашего кода, посмотрите http://beanstalkapp.com/

По личному опыту я бы порекомендовал svn. Вы даже можете использовать такую ​​службу, как Бобовый стебель, которая предлагает бесплатные учетные записи (очевидно, с ограничениями, но достаточными для любого небольшого проекта), чтобы проверить воду. Но, как говорили другие, git лучше и, вероятно, стоит изучить.

Краткий ответ: Subversion, если вы единственный, кто ее кодирует или находитесь на месте со всеми, с кем работаете. GIT, если вы работаете с людьми на разных сайтах и ​​у вас огромная база кода.

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

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

У Coding Horror есть отличный пост о как настроить Subversion в Windows.

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

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

Один из основных советов по упрощению настройки сервера SVN прямо сейчас - использовать виртуальное устройство. То есть виртуальная машина, на которой предварительно установлена ​​и (в основном) предварительно настроена Subversion - в значительной степени вещь plug & play. Вы можете попробовать здесь, здесь и здесь или просто попробовать поискать в Google с помощью «виртуального устройства subversion».

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

Итак, я начал проверять код, одну машину и учетную запись dreamhost. Затем, после того как я случайно удалил функцию и сохранил свой проект, я знал, что нахожусь в глубоком «дуду», но с помощью Subversion я просто проверил последнюю версию этого файла, и ничего не произошло.

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

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

http://www.snee.com/bobdc.blog/2007/08/getting_started_with_subversio.htmlhttp://dojo.jot.com/WikiHome/Getting%20Started%20With%20Subversion

Если вы решите использовать Subversion и хотите разместить свой собственный svn-сервер, тогда есть очень хороший и простой сервер на базе Windows, который называется VisualSVN server. Он скрывает сложность настройки сервера apache, вы просто переходите дальше. Конфигурация пользователя обрабатывается с помощью веб-интерфейса, а не конфигурации

http://www.visualsvn.com/server/

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

Исходя из моего собственного опыта, я бы не рекомендовал git как введение в управление версиями. Я использую его уже пару месяцев, и у меня сложилось впечатление, что он очень мощный и - теперь, когда я частично осмыслил его - достаточно интуитивно понятный. Однако кривая обучения очень крутая, даже несмотря на то, что я использую контроль версий в течение многих лет. Он также страдает от того, что он слишком выразителен - он поддерживает множество различных рабочих процессов и моделей разработки, но единственное руководство по «лучшему» способу его использования - это несколько страниц в глубине поиска Google, что также затрудняет выбор новичком. вверх.

Тем не менее, вполне возможно, что начать с чистого листа с git будет проще - мой опыт работы с VCS основан на централизованном управлении версиями (CVS, SVN, Perforce ...), а часть моих (текущих!) Трудностей с git связана с понимание последствий распределенной модели. Я бегло взглянул на другие DVCS, такие как Bazaar и Mercurial, и они показались мне более удобными для новичков.

В любом случае, как говорили другие, Subversion - это, вероятно, самый простой способ привыкнуть к системе контроля версий и получить практический опыт использования преимуществ VCS (откат, ветвление, совместная разработка, более легкая проверка кода и т. д.).

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

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

Я использую TortoiseSVN в Windows, но на Mac перешел на коммерческий клиент CornerStone вместо (теперь коммерческого) клиента версий. Я обнаружил, что у ряда бесплатных клиентов Mac, включая RapidSVN, было достаточно проблем, чтобы заставить меня выложить реальные деньги. Защитная сетка, которую CornerStone предоставляет для перехвата файлов, которые я забыл добавить в репозиторий, стоит мне денег. Я провожу много времени, сотрудничая с клиентом из США, который находится в противоположном часовом поясе, поэтому не могу позволить себе облажаться, забыв добавить файлы!