Я работаю в отделе, где никто, кроме меня, никогда не использовал систему контроля версий.
Я пытаюсь выдвинуть концепцию. Я потратил немного времени на исследования 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»). Две цитаты из этой статьи, которые я думаю, суммируют.
Что касается мерзавца:
Что касается ртути:
На github можно найти множество проектов, и git является более мощным, но он также может пугать новичков, особенно пользователей Windows. Также есть bitbucket (эквивалент github для mercurial).
Моя рекомендация: начните с Mercurial и, как только вы почувствуете себя комфортно, возьмите git; речь идет не об инструментах, а о людях, с которыми вы работаете .
Реальное и практическое использование Subversion я считаю не для работы с другими людьми, а для того, чтобы, возможно, реализовать программу обновления для ваших производственных приложений, вот почему:
svn up
и ваш проект и его зависимости обновляются.Цитируя Турбьёрна в другой теме :
Редактировать : Если есть VCS, который вы должны знать до Git, это может быть Mercurial (более удобный интерфейс CLI и хорошо знакомый с распределенными концепциями). Этот совет особенно относится к тем, кто прибывает из Subversion, поскольку CLI также в некоторой степени похожи. Распределенный контроль версий легче освоить, чем централизованный контроль версий, поскольку вы просто беспокоитесь о своем экземпляре репозитория, а не о клиентской и серверной частях в отдельности .
источник
Вы должны изучать, что вы собираетесь использовать. Git популярен, так же как Mercurial также пользовался некоторой популярностью. Git / Mercurial - распределенные системы контроля версий.
Самая важная вещь при представлении новой концепции команде (и, к сожалению, контроль версий считается новой темой для слишком большого количества команд), это помогает наметить ваши цели и критерии оценки. Вы не должны быть суперформальными об этом, но задайте себе следующие вопросы:
Оценивая свои альтернативы, вы должны учитывать важные вещи, которые должны делать все VCS:
В конце проведите быструю оценку, чтобы определить, подходят ли стандартные системы VCS или DVCS для вашей команды. Вы должны будете выбрать инструмент, который обеспечивает наименьшее количество боли, или он, вероятно, не будет принят. После этого оцените ваши альтернативы, которые лучше всего соответствуют вашим потребностям.
В конце узнайте, что вы собираетесь использовать.
источник
Я думаю, что многие люди считают Git более сложным, чем SVN, потому что он отличается. После использования subversion (или cvs и т. Д.) Какое-то время может быть сложно мысленно переключать режимы в модель DVCS. Исходя из этого, я бы сказал, что вам следует изучить традиционные VCS, такие как subversion, одновременно с исследованием DVCS, таких как git.
Хотя git - мой любимый VCS, я бы сказал, что лучше всего изучать и Subversion. Во-первых, существует множество хранилищ subversion и cvs, с которыми вам, возможно, придется взаимодействовать в один прекрасный день, а также у вас будет лучшее понимание точных преимуществ и недостатков DVCS по сравнению с традиционными VCS.
источник
git-svn clone
для взаимодействия с хранилищем.Было бы неэффективно изучать SVN, а затем Git
Вот несколько причин:
Мой совет - просто учиться мерзавцу.
источник
В GIT и SVN некоторые вещи примерно одинаковы, а некоторые нет.
Вообще то же самое, вы должны легко подобрать его.
Разное между двумя.
Не говорить, что вы должны или не должны меняться сейчас (я думаю, что это ваш призыв), просто хотел указать на это, так как это что-то принять во внимание. Если вы уверены, что хотите попробовать Git, вы можете переключиться сейчас, чтобы сэкономить на изучении чего-то в SVN, что отличается от Git.
источник
Вау; 12 ответов и все еще задают вопрос ...
Нет, Subversion не является обязательным условием для Git.
Между Subversion и Git нет четкого сопоставления - если вы планируете изучать оба, вам просто придется страдать из-за того, что они используют одни и те же термины для различных действий. (И разные термины для одних и тех же действий.)
svn commit
это другая вещь, чемgit commit
.Это два инструмента, разделенных общим языком.
Ваш вопрос и большинство других ответов предполагают, что 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.
источник