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

Ответ 1

Похоже, вам нужен какой-то источник управления! Вы вообще посмотрели на Subversion (SVN)? Для этого существует удивительный клиент Windows, называемый TortoiseSVN. Оба являются свободными и открытыми.

Вы должны настроить сервер Subversion на одном из ваших компьютеров или на каком-либо веб-сервере. Затем вы оба фиксируете свои изменения на сервере через регулярные промежутки времени, и сервер управляет такими вещами, как ревизия, комментарии, которые вы прикрепляете к коммиттам и т.д. С клиентом вы можете делать такие вещи, как просмотр различий между изменениями и слиянием изменений (автоматически или вручную) в файлах. Это также упрощает добавление других разработчиков в ваш проект, просто дайте им доступ к вашему серверу Subversion. Существуют SVN плагины для Eclipse и Visual Studio, или вы можете использовать TortoiseSVN, который может работать автономно на командной строке и интегрируется с оболочкой Windows (см. ниже).

Интеграция оболочки TortoiseSVN http://olex.openlogic.com/wazi/wp-content/uploads/2009/03/create_repo_tortoisesvn.png

Вещь, которая мне больше всего нравится в TortoiseSVN, заключается в том, что она полностью независима от языка или IDE, и я могу использовать ее для проектов Java из проектов Eclipse,.NET из VS2008 или для разработки драйверов на C/С++.

Обратите внимание, что инструмент SubWCRev, поставляемый с TortoiseSVN, также предоставляет COM-интерфейс, который позволяет вам делать классные вещи, например, программно проверять, кто сделал last commit и когда, какой последний номер версии и т.д. Я упоминаю об этом, потому что об этом не так много информации, кроме как в документах TortoiseSVN, и мне было очень полезно в последнее время написать VS2008 addin, который я использую на моих .NET-проектах, чтобы автоматически синхронизировать номер версии и номер сборки приращения.

Несколько сайтов предоставляют бесплатный доступ к хранилищу SVN для проектов с открытым исходным кодом (или платный доступ для закрытых исходных/коммерческих продуктов), таких как Google Code и Sourceforge. Эти онлайн-хранилища также могут быть действительно полезны для работы над проектом, особенно если вы участвуете в групповом проекте.

Ответ 2

Тип программного обеспечения, который вы ищете, - это управление источником (также называемое контролем версий). Это огромная тема, но я бы начал ее искать в Википедии, а затем ищет тип источника управления, который работает с языком и инструментами, которые вы используете. (Пример Team Foundation Server в качестве опции для Visual Studio, SVN для хорошего решения для всех и т.д.)

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

Ссылка в Википедии:

http://en.wikipedia.org/wiki/Revision_control

Ответ 3

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

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

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

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

Несколько вещей, о которых нужно подумать:

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

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

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

Ответ 4

Если вы хотите немного узнать о Git, вы можете разместить свою работу на github.com и все еще работать над ней отдельно.

Ответ 5

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

Использование инструмента в вашем случае очень простое. Выберите систему контроля версий и научитесь ее использовать. Вариантов много, но самым важным фактором является поддержка инструмента. Например, инструменты типа tortuise отлично подходят для пользователей Windows (TortuiseSVN, ToruiseCVS, TortuiseHg), поскольку они интегрируются в оболочку Windows и позволяют увидеть, что произошло с каждым файлом и каталогом, применяя к ним различные значки (красный восклицательный знак для изменения, зеленый ОК и т.д.).

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

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

По моему мнению, здесь есть две важные вещи:

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

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

Вот пример простого процесса:

• Установить сервер репозитория (svn, mercuiral и т.д.). Для вас единственная разница - поддержка инструмента.
• Согласование общей структуры репозитория (Documents, Source, Extras)
• Обновление в начале каждого дня
• Зафиксировать часто, прежде чем каждое обновление фиксации из репозитория
• В конце каждого дня совершать

Ответ 6

Контроль источника исследования. Здесь хорошее введение:

http://www.ericsink.com/scm/source_control.html

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

Ответ 7

за последние 6 месяцев я перешел на git и очень доволен этим. но в общем случае cvs | svn | git являются наиболее распространенными SCM с открытым кодом (управление исходным кодом), и любой из них должен быть в состоянии удовлетворить ваши потребности.

Ответ 8

"или какой-то клиент совместного доступа, который мы могли бы использовать

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

Вы подписываетесь на бесплатную учетную запись на 2 ГБ с именем пользователя/паролем, совместно используемым между вами и вашим другом. Затем вы устанавливаете клиент DropBox как на своем, так и на своем ПК друзей и используете общую учетную запись.

После запуска Dropbox создает папку в разделе Мои документы с именем "Мой Dropbox". Теперь все, что вы делаете в этой папке, например создание, редактирование, удаление файлов и папок, будет автоматически синхронизироваться с папкой "Мой Dropbox" на вашем ПК друзей и наоборот. Доступ в Интернет - это все, что требуется.

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

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

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

Ответ 9

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

Глядя на ваше сообщение, вы хотите:

• Простая с простой настройкой и использованием
• Обмен кодом (просмотр и изменение)
• Видя, кто изменил, что и когда

Я бы порекомендовал Git, потому что ответы на три с базовым инструментом Git и Github.com или Bitbucket.org.

CVS и SVN являются тяжелыми и не имеют очень удобного веб-интерфейса, такого как Github или Bitbucket. И хотя я был отличным поклонником CVS и перешел на SVN, я должен признать, что они сейчас очень вкусные, по сравнению с новыми системами Git и подобных.