Что такого хорошего в git?

Ответ 1

Наверху:

• его распределенный аспект (у каждого разработчика есть копия репозитория)
• Способность обрабатывать сложные слияния очень быстро
• возможность перехода от задачи к задаче, отложить его работу, вернуться к ней...
• дешевое ветвление (мгновенный переключатель: он просто записывает несколько бит в файл! И он не рассматривает ветвь как каталог, такой как SVN)

Основная трудность состоит в том, чтобы установить workflow между различными репозиториями, не нарушая историю то, что уже было опубликовано (перенаправлено на публичное репо).

В частности, rebase может быть сложно правильно использовать, поскольку она переписывает историю ветки и изменяет связанный с ней SHA1: в публичную ветку, которая означает много слияний с другими разработчиками, тянущимися от него.

Ответ 2

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

Тем не менее, git может многое предложить. Не углубляясь в wizardry git, вы можете быстро научиться использовать некоторые из его самых популярных аспектов: возможность локально проверять, не нажимая вверх по течению до основного репо, и почти полностью без проблем разветвляться и сливаться.

У вас может быть очень удовлетворительный git опыт с базой нескольких команд.

Из всех ресурсов там, Скотт Чакон Получение Git - это то, что продало меня по преимуществам git и дало мне побуждение проталкивать крутую часть кривой обучения.

Ответ 3

Github! Действительно, я только научился ценить git с помощью github.

Ответ 4

Git работает очень быстро и хранит репозитории очень компактно (думаю, от одной десятой до сотой размера одной и той же базы кода + история в svn). Git (и наиболее распространенный VCS) дают вам дешевые ветки, которые безболезненно порождаются, обрабатываются и сливаются. Все это происходит локально, и члены команды не отвлекаются на постоянную работу товарищей по команде, если не будут предприняты активные попытки поделиться ею.

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

Я бы порекомендовал сначала получить удобство с ним в качестве клиента, поговорив с github или аналогичным инструментом.

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

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

Ответ 5

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

Я предлагаю посмотреть wiki git: http://git.or.cz/gitwiki и официальный сайт: http://git-scm.com/

Надеюсь, это поможет, и вам понравится использовать git.

Ответ 6

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

Ответ 7

Многие говорят о том, как использовать сложный git, но ничего не стоит, если вы придерживаетесь очень простого шаблона использования git, не сложнее, чем сказать RCS.

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

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

Лично я использовал его в основном для личных проектов и для локального контроля версий на работе. Мы используем perforce на работе, и они довольно строги относительно количества веток, которые мы можем сделать в том, что мы можем проверить. Нам нужно проверить готовые, компилируемые, проверяемые фрагменты кода.

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

Итак, для меня большие точки продаж git:

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

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

Ответ 8

История GIT является классикой в ​​истории FOSS. См. history GIT в Википедии. Теги для этой истории: BitKeeper, Andrew Tridgell, Torvalds, Git, самостоятельно размещены за 2 дня.

Ну, а не ответ, кто-то с отношением FOSS/Hacker, несомненно, будет любить его читать.