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

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

Из того, что я прочитал в Интернете, кажется, что gitэто лучше знать, но и сложнее. Я не хочу подавлять себя. Должен ли я продолжать осваивать SVN перед переходом на Git или мне было бы разумнее просто перейти к Git сейчас?

Есть ли плюсы и минусы в обоих подходах?

нет

Git настолько радикально отличается от SVN, что вам не поможет. Во всяком случае, вы будете искать команды «update» и «commit» и удивляться, почему все по-другому.

Начните с Git снизу вверх и идите оттуда.

Контраст стандартной системы централизованного управления версиями шаблонов обновления / фиксации с Git подобен сравнению шины с массовым транзитом. Автобус доставит вас (и всех остальных) из пункта A в пункт B по тому же маршруту. Общественный транспорт доставит вас из пункта А в пункт Б, используя любой маршрут, который вам нравится.

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

Редакция хэшей против чисел

Кто-то упоминал, что Git использует хэши SHA1, а Hg использует числа.

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

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

Нет, пожалуйста, даже не беспокойтесь.

Серьезно, начните с DVCS. Тот факт, что SVN популярен, не делает его стандартом. Линус Торвальдс скажет вам, что это может загнить ваш мозг .

Прочитайте эту большую статью / привнесение Джоэл Спольски называется Subversion перевоспитание .

Вам также может быть интересно прочитать этот другой вопрос: я фанат Subversion, почему я должен рассмотреть или не рассмотреть Mercurial или Git или любой другой DVCS?

Выбор между DVCS

Лично я использую и Mercurial, и Git, и я думаю, что важно знать оба. Рекомендуемое прочтение: « Git против Mercurial: пожалуйста, расслабьтесь» (см. Пример «git-addremove»). Две цитаты из этой статьи, которые я думаю, суммируют.

Что касается мерзавца:

Философия дизайна Git безошибочна: Unix: в отличие от Subversion, CVS или Mercurial, git - это не один монолитный двоичный файл, а множество отдельных инструментов, начиная от высокоуровневых «фарфоровых» команд, таких как git-pull, git-merge и git-checkout для низкоуровневых «слесарных» команд, таких как git-apply, git-hash-object и git-merge-file. Таким образом, как и MacGyver, вы можете делать с Git практически все, что вам нужно - это включает в себя совершенно потрясающие движки Wiki, средства отслеживания ошибок, файловые системы, инструменты sysadmin - все, кроме восстановления предохранителей.

Что касается ртути:

Разработчики, которым нравится поддерживать свою систему в чистоте, вероятно, оценят тот факт, что hg устанавливает один двоичный файл, в отличие от 144, которые составляют git, а разработчики, которые считают, что способность git редактировать ваши предыдущие коммиты является идиотской, ненужной и опасной, оценят Простота HG обеспечивает, опуская эту особенность.

На github можно найти множество проектов, и git является более мощным, но он также может пугать новичков, особенно пользователей Windows. Также есть bitbucket (эквивалент github для mercurial).

Моя рекомендация: начните с Mercurial и, как только вы почувствуете себя комфортно, возьмите git; речь идет не об инструментах, а о людях, с которыми вы работаете .

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

• В настоящее время svn почти установлен в большинстве хостинг-провайдеров.
• Имеет хорошую поддержку подпроектов (хотя теперь адресуется в git и hg). svn upи ваш проект и его зависимости обновляются.

Цитируя Турбьёрна в другой теме :

DVCS - это Subversion, что такое Bittorrent для ftp

Редактировать : Если есть VCS, который вы должны знать до Git, это может быть Mercurial (более удобный интерфейс CLI и хорошо знакомый с распределенными концепциями). Этот совет особенно относится к тем, кто прибывает из Subversion, поскольку CLI также в некоторой степени похожи. Распределенный контроль версий легче освоить, чем централизованный контроль версий, поскольку вы просто беспокоитесь о своем экземпляре репозитория, а не о клиентской и серверной частях в отдельности .

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

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

• Какова цель контроля версий в нашей команде. Да, все системы контроля версий, которые чего-либо стоят, позволят вам вернуться в историю и посмотреть, что изменилось в любом файле. Тем не менее, вы собираетесь использовать его для создания новых релизов? (кивни головой, хочешь этого). Это утверждение из 2-3 строк о том, чего вы хотите достичь.
• Ваша команда привыкла иметь собственную местную рабочую среду только для того, чтобы потом аккуратно сливать вещи? Если это так, маршрут DVCS может иметь больше смысла.
• И наоборот, ваша команда работает с одним общим диском, и все в постоянной интеграции? Если так, более традиционный VCS мог бы иметь больше смысла.

Оценивая свои альтернативы, вы должны учитывать важные вещи, которые должны делать все VCS:

• Базовый код (помеченные ветви, метки и т. Д.). По сути, как вы получаете точный исходный код, используемый в выпуске вашего проекта.
• Получить локальные изменения на центральном сервере. Должна быть авторитетная копия кода - используете ли вы DVCS или стандартную VCS. Каждый инструмент относится к этому процессу по-своему.
• Получите изменения на центральном сервере в вашу локальную копию.
• Как бороться с экспериментальными изменениями. VCS позволяют вам быть более смелыми с предлагаемыми изменениями, не нарушая основной исходный код проекта. DVCS и стандартные системы VCS подходят к этому совершенно по-разному - одна из них лучше всего подойдет вашей команде.
• Как вы устанавливаете и настраиваете серверы?
• Вам нужна аутентификация? Если да, то как вы можете убедиться, что на самом деле это могут делать только те люди, которым разрешено вносить изменения?

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

В конце узнайте, что вы собираетесь использовать.

Я думаю, что многие люди считают Git более сложным, чем SVN, потому что он отличается. После использования subversion (или cvs и т. Д.) Какое-то время может быть сложно мысленно переключать режимы в модель DVCS. Исходя из этого, я бы сказал, что вам следует изучить традиционные VCS, такие как subversion, одновременно с исследованием DVCS, таких как git.

Хотя git - мой любимый VCS, я бы сказал, что лучше всего изучать и Subversion. Во-первых, существует множество хранилищ subversion и cvs, с которыми вам, возможно, придется взаимодействовать в один прекрасный день, а также у вас будет лучшее понимание точных преимуществ и недостатков DVCS по сравнению с традиционными VCS.

Было бы неэффективно изучать SVN, а затем Git

Вот несколько причин:

• Гиты в корне отличаются от свн. Git недоволен, а svn - клиент / сервер.
• Различные значения связаны с одними и теми же словами. Например, «git checkout ...» имеет значение, отличное от «svn checkout ...»
• Ветвление другое. В Git есть концепция веток 'theme', которые представляют собой дешевые локальные ветки, которые svn не поддерживает.
• У Git есть дополнительное место, называемое индексом, которое находится между рабочим деревом и вашим хранилищем. У Svn нет индекса. Используя git, ваши изменения перемещаются из вашего рабочего дерева в индекс в хранилище.

Мой совет - просто учиться мерзавцу.

В GIT и SVN некоторые вещи примерно одинаковы, а некоторые нет.

Создание / обновление / контроль / фиксации

Вообще то же самое, вы должны легко подобрать его.

как пометить и разветвить, но все еще сильно запутался в конфликтах между ветвями, транком и т. д.

Разное между двумя.

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

Вау; 12 ответов и все еще задают вопрос ...

Нет, Subversion не является обязательным условием для Git.

Между Subversion и Git нет четкого сопоставления - если вы планируете изучать оба, вам просто придется страдать из-за того, что они используют одни и те же термины для различных действий. (И разные термины для одних и тех же действий.)

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

Это два инструмента, разделенных общим языком.

Ваш вопрос и большинство других ответов предполагают, что git - это своего рода svn ++; "Лучше свн". Это не так. Это два разных инструмента, которые работают в одном и том же пространстве, например, в автомобиле или мотоцикле.

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

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

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

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

Посмотрите на Mercurial (если вы не хотите, чтобы ошеломить).

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

Стоит изучать Git, пока у вас есть возможность уничтожить свой разум Subversion.

Я не думаю, что понимание Subversion необходимо для понимания Git.

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

Мне действительно нравится git в среде Unix (Linux, MacOS X). В окнах это немного хакерски. Я хотел бы рассмотреть Mercurial, если у меня есть Windows в уравнении.

Если вам понравились занятия по истории, попробуйте SCCS, RCS, CVS, Subversion, а затем используйте что-нибудь полезное, например, Git или Mercurial.

Git и Mercurial равносильны, большой бонус Git - github . Но если вы не хотите передавать управление версиями на аутсорсинг, github больше не участвует в уравнении.

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

Вы можете изучать Git сейчас и потратить время на изучение Suvbersion позже, если вам нужно.

Нет. Скачайте Git, создайте учетную запись на github и возитесь в течение нескольких дней, разыгрывая репо и т. Д. Git довольно прост в освоении. Изучите 5 или 6 команд bash, и вы сможете выполнять все основные задачи. Я вообще предпочитаю "идиотостойкость" графического интерфейса, но Git Bash примерно такой же простой, как и раньше. Кроме того, Git Gui довольно приличный, если вы предпочитаете этот маршрут. Я действительно не вижу выгоды, которую вы бы получили от изучения SVN. Некоторое время назад я проходил период, когда оценивал несколько разных систем контроля версий для нового проекта с открытым исходным кодом. Я опробовал SVN, Bazaar, Git и пару других и изучил основы каждого из них. YMMV, но Git был намного проще всего. Нет ничего плохого в изучении SVN, но это действительно не поможет вам выучить Git.