Контроль версий: взятие проекта без каких-либо

Question

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

Мой вопрос: с чего начать внедрение контроля версий в проекте, который уже находится в производстве? Учитывая, что раньше я не использовал контроль версий, так что на самом деле это два отдельных вопроса:

• Начиная с контроля версий
• Реализация на уже живом Проект

Для справки, проект представляет собой php / mysql-сайт, использующий кусочки javascript, я работаю на сервере (Windows) XAMPP и очень заинтересован в изучении этого нового мира контроля версий!

Answer 1

Поздравляем, вы движетесь в правильном направлении!

Сначала вам нужно выбрать систему контроля версий. Мой текущий фаворит - Git. К сожалению, я не думаю, что Git - это простое введение в контроль версий. Я также использовал Subversion и Perforce.

Subversion (http://subversion.tigris.org/) работает на многих платформах, используется во многих проектах и ​​имеет несколько хороших инструментов GUI (таких как TortoiseSVN в Windows). Инструменты командной строки также доступно. Это также бесплатно. Вы можете запустить его в режиме "локальной файловой системы", что означает, что вам не нужно настраивать отдельный сервер. Он далек от его корней "лучше, чем CVS".

Perforce (http://www.perforce.com/) довольно хорош. Его реализация Windows кажется лучшей (в прошлом я проверял, их кроссплатформенный графический интерфейс был довольно паршивым). Вы в основном используете GUI для взаимодействия с ним, хотя опять-таки есть инструменты командной строки. Это коммерческое программное обеспечение, но проекты с открытым исходным кодом могут получить бесплатные лицензии, связавшись с компанией. Самое большое затруднение в том, что вам потребуется настроить сервер. Для начала вы можете запустить сервер на том же компьютере Вы продолжаете развиваться, но это, вероятно, плохая идея в долгосрочной перспективе. Я считаю, что Perforce очень хорош для команд из 2-8 человек, я не знаю, насколько хорошо он будет работать с большим количеством.

Большим преимуществом Git (http://git -scm.com / ) является то, что он практически не требует настройки. После установки вы можете выполнить git init в любом каталоге, чтобы создать новый репозиторий git. История изменений хранится в каталоге проекта. Вы можете начать только с локального управления версиями, и вы можете увеличить масштаб оттуда. Если Git кажется страшным, вы также можете проверить Mercurial (https://www.mercurial -scm.org / ). Я не использовал его, но я понимаю, что он использует те же принципы, что и Git.

Избегайте CVS. Он находится на выходе, и ни один новый проект не должен использовать его, если они не должны это делать.

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

Answer 2

Начните здесь: http://svnbook.red -bean.com /

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

Answer 3

Будьте готовы к некоторому сопротивлению со стороны руководства и / или ваших коллег. Руководство может не захотеть инвестировать ресурсы для машины хранилища - эти вещи должны быть установлены, поддерживаться, резервироваться и т. Д. Или они могут возражать против того, чтобы вы тратили время на «дополнительные» функции, такие как RCS.

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

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

Поиграй с этим. Проверьте файлы в отдельном рабочем пространстве и взломайте вещи, зная, что это не имеет значения; Вы всегда можете отменить это. Узнайте, как использовать новый инструмент с некоторыми интерфейсами GUI (мне самому нравится 'svn diff --diff-cmd = kdiff3'). Перейдите к точке, в которой вы знаете, как регистрировать, маркировать вещи, переходить и объединять. Тогда покажи своим сотрудникам.

Лично мне нравится SVN, но я не выбрал его; он выбрал меня.

Answer 4

Шаг 1: Загрузить Mercurial .

Шаг 2: В вашей любимой командной строке перейдите в корень вашего исходного каталога и введите hg init.

Шаг 3: Сделайте make clean или эквивалент (т. Е. Все, что вам нужно, это источник, без сгенерированных файлов).

Шаг 4: Введите hg addremove.

Шаг 5: Введите hg commit.

С этого момента вы можете:

• Изучите изменения между вашим последним коммитом и сейчас: hg diff или hg status.
• Сделайте контрольные точки в вашем коде: hg commit.
• Возврат к предыдущим контрольным точкам: hg update -C -r 0

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

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

Answer 5

Первое, что нужно сделать, это выбрать парадигму контроля версий (централизованная или распределенная). Чтобы ответить на это, вам нужно взглянуть на свою команду и на то, как вы собираетесь обрабатывать регистрацию, регистрацию, слияние и ветвление. После того, как вы выберете парадигму, вы можете выбрать систему контроля версий. Основными системами являются Subversion для централизованного контроля версий и Git и Mercurial для распределенного контроля версий.

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

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

Answer 6

Я не знаю, есть ли что-то подобное для php и т. Д., Но интересный ресурс здесь "Разработка приложений Brownfield в .NET" . Во многих случаях это использует только .NET для примеров; большая часть книги посвящена политике, как вы упомянули:

• как ввести управление исходным кодом
• как ввести юнит-тестирование
• как ввести непрерывную интеграцию
• и т.д.

и все проблемы / соображения, связанные с ними.

Частично относится к коду; но также относящийся к «человеческому» фактору; коллеги, менеджеры и т. д. Я очень рекомендую это; но вы можете решить, что фон .NET вам не подходит (он мне подходит ;-p).

Answer 7

У меня есть опыт работы только с SourceSafe и SVN.

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

SVN это хорошо, его просто установить на Linux или Windows. Большинство IDE имеют плагин для него, и если вы используете Windows, есть расширение Explorer (TortoiseSVN), которое позволяет вам выполнять все операции прямо из Windows Explorer. Существует множество инструментов SVN для каждой ОС, они очень хорошо поддерживаются. SVN также интегрируется с TRAC (системой отслеживания ошибок) и Bugzilla, так что вы можете связать свои рабочие билеты с кодом.

Я скажу, что [КАК вы используете управление версиями, вероятно, так же, если не более важно, чем какой пакет вы используете] [2]. Использование ее просто в качестве библиотеки - очень простое приложение, но для команды из 1-2 человек, создающей веб-сайт или приложение, в котором вы не будете поддерживать сборки и версии, все будет в порядке.

Когда дело доходит до контроля версий, все лучше, чем ничего.

Answer 8

Я узнал концепции из прагматического ряда: пример для subversion , у них также есть книги по GIT.

Answer 9

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

ОК, чтобы ответить на ваш вопрос, как вы помещаете проект в систему контроля версий?

Это не так сложно, как только вы выбираете утилиту контроля версий (будь то git, svn, hg, bzr ... что угодно), обычно есть команда или две для инициализации хранилища, а затем добавляются все соответствующие файлы. 1005 *

Например, в git это может быть что-то вроде:

$git init
$git add --all
$git commit -m"First commit"

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

Популярность Git / Mercurial / Bazaar против того, что рекомендовать

Единственными инструментами, которые вы должны рассмотреть, являются:

• git
• svn (Subversion)
• hg (Merculiar)
• bzr (базар)
• mtn (монотонный)

Все остальное либо старое, либо коммерческое.

svn следует модели сервер-клиент; есть центральное хранилище. Если вы работаете в команде из одного человека, то единственное, что для вас значит, - это настроить сервер и убедиться, что он запускается с компьютера. Хотя я слышал, что вы можете покончить с сервером. Немного погуглив, появляется это руководство по использованию svn без сервера

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

Преимущество svn в том, что он был там некоторое время, имеет множество интерфейсов графического интерфейса и лучшую интеграцию с IDE.

Я не могу сравнить git с hg (по-особенному), так как я не использовал последний, но git имеет уникальную модель хранения по сравнению с svn и hg.

говорят, что bzr проще в использовании, но медленнее (написано на python).

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

Answer 10

дополнение к другим ответам:

Если в проекте, который вы хотите поставить под контроль версий, было несколько выпусков, и если эти версии доступны, например, в виде tar-файлов (например, project-0.1.tar.gz, project-0.2.tar.gz, project-0.3.tar.gz, ...), вы можете захотеть рассмотрите возможность импорта этих версий в выбранную вами систему контроля версий. Например, в Git есть import-tars.perl и import-zips.py в каталоге contrib/fast-import/, а также поддержка записи других файлов на других языках программирования для git быстрый импорт должен быть легким.

Sidenote: моя предпочтительная система контроля версий - Git .

См. Также: Хорошая ссылка или книга по основам и теории управления версиями вопрос.