Скорее всего, здесь никто ничего не продаст. Если вам нужны функции git, просто git init. Если он вам не подходит, просто не подходите.

Если вы еще не знаете функции git, введите git vs (обратите внимание на конечный пробел) в поиске Google и просмотрите результаты автозаполнения.

Я предпочитал Notepad, а не IDE, пока мне не понадобились функции Netbeans. Кажется, что это тот же самый случай здесь.

Как вы знаете, было много успешных проектов вообще без VCS.

PS. Продажа git нарушает его лицензию! ;)

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

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

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

РЕДАКТИРОВАТЬ: Вы можете использовать DVCS как централизованный репозиторий, и я бы даже рекомендовал делать это, по крайней мере, для проектов малого и среднего размера. Наличие одного центрального «авторитетного» репозитория, который всегда находится в сети, упрощает многие вещи. И когда эта машина выходит из строя, вы можете временно переключиться на одну из других машин, пока сервер не будет исправлен.

DVCS очень интересен для меня, так как он:

• добавляет совершенно новое измерение к процессу управления исходным кодом : публикация .
  У вас есть не только рабочий процесс слияния , но и рабочий процесс публикации (в какой репозиторий вы будете нажимать / извлекать), и это может иметь множество последствий в перспективе of:

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

• предлагает новый способ создания / использование ревизий с:

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

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

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

Функции истории IDE ограничены и неуклюжи. Они не похожи на полнофункциональные.

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

Интересный вопрос.

Я не опытный пользователь DVCS, но мое ограниченное знакомство с ним очень положительно.

Мне нравится возможность двухэтапной фиксации. Меня это устраивает.

Некоторые преимущества, которые приходят на ум:

1. Лучшая поддержка слияния. Branch-Merge больше похож на гражданина 1-го класса в DVCS, тогда как по моему опыту централизованных решений я обнаружил, что это болезненно и сложно. Теперь в svn доступно отслеживание слияний, но оно по-прежнему медленное и громоздкое.

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

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

Обратите внимание, что мой опыт работы с DVCS больше связан с Mercurial, чем с Git.Исходя из опыта работы с CVS / SVN, я обнаружил, что обучение с Mercurial (Hg) намного проще. Недавно добавленная поддержка Google Code для Mercurial также является благом. ... Я даже могу сказать, что мой первоначальный ответ на Git был отрицательным, но больше с точки зрения удобства использования, чем с точки зрения удобства использования. делать с DVCS

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

В другом недавнем сообщении говорится, что Subversion не пытается стать DVCS.

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

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

Пока однажды я не набрал git init и внезапно не оказался внутри репозитория git.

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