У меня была эта проблема, решение заключалось в том, чтобы посмотреть на график фиксации (используя gitk) и увидеть, что у меня было следующее:
* commit I want to cherry-pick (x)
|\
| * branch I want to cherry-pick to (y)
* |
|/
* common parent (x)
Теперь я понимаю, что хочу сделать
git cherry-pick -m 2 mycommitsha
Это связано с тем, что -m 1
будет сливаться на основе общего родителя, где слияние -m 2
основано на ветве y, то есть тот, который я хочу, чтобы выбрать cherry-pick.
Обновление, ноябрь 2011 г .:
Git теперь намного более зрелый по сравнению с 2009 г .:
Однако установка Git в централизованной среде не является тривиальной:
не сам файл: два файла с одинаковым содержимым будут сохранены только один раз)
Это означает:
Я использую и рекомендую mercurial
С момента зарождения социального кодирования с помощью Git на GitHub , Git, похоже, привлек множество последователей.
Причина, по которой у git так много пользователей, заключается в том, что его использует ядро Linux, поэтому, если вы хотите заниматься разработкой для Linux, используйте git.
Поскольку очень много людей занимается git, я бы рекомендовал использовать git просто из-за большей базы пользователей. Фактически, цифры, которые вы показываете выше, являются явным признаком этого.
Что касается сложности, то любой контроль версий затруднен, особенно распределенный. На первый взгляд, SVN и CVS были непростыми (по крайней мере для меня). Это лишь часть необходимого обучения, чтобы привыкнуть к системе контроля версий.
РЕДАКТИРОВАТЬ: Поскольку вы добавили ссылку на подрывную деятельность, я решил, что обращусь к ней. Я думаю, что большинство людей будет использовать svn, потому что для него есть всевозможные красивые графические интерфейсы. В целом, люди, в том числе и некоторые разработчики, ненавидят использовать командную строку. git обычно не очень хорошо работает и в Windows (или, по крайней мере, не так гладко). Поскольку многие люди используют Windows, это убивает количество потенциальных пользователей.
Кроме того, я думаю, что концепции SVN немного легче понять, поскольку svn использует центральный репозиторий, а не распределенную систему. Легче понять: «Вот большая гора кода, пожалуйста, добавьте сюда свой код», чем «Вот какой-то код, мой может отличаться от его, его от ее, но вы можете добавить что-нибудь, если хотите»
На мой взгляд, в svn установлена гораздо лучшая система документации. Документация git ориентирована на немного более высокий уровень знаний (программы, а не интеллекта программистов) и поэтому имеет смысл после того, как вы используете систему, но при первом запуске она просто выглядит как набор gobbeldy-gook.
В целом, я думаю, что svn был и всегда будет более распространенным, потому что его общие принципы работы проще для понимания, инструменты просты в использовании, и он прекрасно поддерживается в Windows.
Позвольте мне закончить моими последними двумя центами и сказать, что я предпочитаю git, потому что я думаю, что он намного мощнее любой другой системы, которую я использовал. Подъем по кривой обучения определенно окупается, если вы начнете лучше понимать программу.
[ПРИМЕЧАНИЕ: с выпуском Subversion 1.7 первый абзац в моем ответе ниже устарел, поскольку теперь Subversion просто создает одну папку «.svn» в базовой папке, аналогично остальным сейчас.]
Одно из преимуществ любого из трех перед Subversion состоит в том, что он не создает эквивалент папки «.svn» в каждой папке проекта. Обычно в базовой папке есть только один («.hg», «.bzr» или «.git»). Одно это может быть хорошей причиной использовать один из них вместо svn, даже если вы используете модель централизованного репозитория. (В сторону: на самом деле, я часто использую svk в качестве своего svn-клиента при использовании репозитория svn только для этой функции (хотя только для Linux, svk не подходит для Windows)).
Конечно, один преимущество подрывной деятельности в том, что вы не делаете
Судя по количеству вопросов на этом сайте по этим трем распределенным системам управления версиями, кажется, что Git либо
- более популярен, либо
- сложнее (следовательно, требуется больше вопросы), или
- имеет больше функций (следовательно, требует больше вопросов).
О SCM популярности - см. следующий вопрос на StackOverflow: Имеется ли статистика популярности / использования для Бесплатные системы RCS / SCM / VCS? . Здесь у нас есть вопросы, например, какой набор игнорируемых файлов использовать для конкретного типа проекта, которые не зависят от SCM, но запрашиваются для Git (и с использованием тега 'git'), потому что это то, что использует человек, задавший вопрос.
О том, что Git более сложен (и, следовательно, у него больше вопросов по SO) - безусловно, у Git более крутая кривая обучения. Он также использует несколько (совершенно) уникальных концепций, таких как промежуточная область (индекс) или равенство всех ветвей, которые несут ответственность за его мощность, но может быть трудно понять сначала (особенно если один исходит из другого SCM) . Кроме того, пользовательский интерфейс Git не является полностью согласованным (хотя он становится лучше), потому что он был выращен, а не разработан; который отвечает за его мощность, но может привести к неоптимальному пользовательскому интерфейсу.
О Git, имеющем больше функций - вам нужно будет проверить, сколько SO-вопросов касается расширенных / необычных функций Git. Однако вы должны знать, что проекты с открытым исходным кодом заимствуют идеи друг у друга или имеют аналогичные функции, разработанные независимо: одним из примеров может быть поиск ошибок путем разделения (поиска) истории для фиксации, которая привела к ошибке, которая была (насколько мне известно) разработана. сначала в Git, а затем реализован как плагин в Bazaar и первое расширение и в настоящее время основная функциональность в Mercurial. Другой вариант - интерактивный выбор фрагментов изменений для фиксации, вдохновленный поведением Darcs. Еще одна идея пакета Git, заимствованная из аналогичной концепции в Mercurial.
Еще одной возможностью источника большего количества вопросов SO может быть отсутствие хорошей документации ... хотя в настоящее время ситуация улучшается с Руководство пользователя Git (распространяется с Git) и Книга сообщества Git (находится на домашней странице Git). Тем не менее существует постоянный мем о том, что у Git документация хуже, чем, скажем, у Subversion с его Контроль версий с Subversion (также известный как svnbook ) и Mercurial: Окончательное руководство (также известное как hg-book ) ... и люди иногда не читают документацию, прежде чем задать вопрос о StackOverflow.
Не совсем удовлетворительно иметь три конкурирующих, но в значительной степени эквивалентных продукты с открытым исходным кодом на выбор. Лично я использую Git, и мне нравятся два других. Но когда дело доходит до рекомендации одной системы по сравнению с другими, я хотел бы спросить: можем ли мы начать безопасно рекомендовать одну?
Что ж, Git и Mercurial были разработаны независимо, начиная почти в одно и то же время в ответ на прекращение бесплатного использования лицензия на BitKeeper для использования разработчиками ядра Linux в качестве его замены. О Subversion как о централизованном SCM не могло быть и речи, с отсутствием поддержки (тогда) в ядре для отслеживания слияния; это сделало его совершенно непригодным для широко распределенной модели разработки ядра Linux. Базар, вероятно, был слишком медленным (по крайней мере, тогда) и немного централизованным (я думаю).
Git более мощный (на мой взгляд), Mercurial проще (по мнению людей) и немного более портативен (Python); Git поддерживает сценарии и основан на модели данных, допускающей независимые переопределения (см., Например, JGit, git, написанный на Java), в то время как Mercurial имеет привязки Python для написания расширений и в значительной степени основан на API, позволяющем изменять базовый формат репозитория (revlog - revlog-ng ) ... но это только мое предположение. Они занимают несколько иные ниши.
Кроме того, отсутствие выбора считается хорошим делом? У нас есть KDE, и у нас есть GNOME и XFCE (и другие оконные менеджеры и окружение рабочего стола); у нас есть Emacs и Vim (и другие редакторы программистов); у нас есть дистрибутивы на основе rpm (например, Fedora Core, Mandriva, SuSE) и на основе deb (Debian, Ubuntu), на основе tgz (Slackware) и на основе исходного кода (Gentoo); у нас есть KWord, AbiWord и OpenOffice.org ... и у нас есть Git, Mercurial и Bazaar.
По моему опыту, судя по количеству вопросов, сравнение с git и с Mercurial заметно искажает картину. Причина двоякая:
Посмотрите на hg update --help
в сравнении с git checkout -h
и git --help checkout
. С Mercurial я редко находил вопросы, на которые не давали ответа несколько взглядов на hg help
.
Загляните в Mercurial Wiki - если вам нужна помощь, вы, скорее всего, найдете ее там, включая множество советов и рекомендаций: http://mercurial-scm.org/wiki/TipsAndTricks