Как вы используете Git в Eclipse, как это было задумано?

Question

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

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

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

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

Заранее спасибо, Алексей Блю.

Answer 1

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

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

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

Другими словами, вы должны быть готовы к созданию серверов Git (например, см. http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux, но есть и другие руководства для этого) и определить рабочие процессы для вашей собственной компании, которые будут его использовать.

Кроме того, я рекомендую посмотреть серию блогов AlBlue под названием Git Tip of the Week .

Наконец, чтобы упростить введение, я предлагаю сначала представить Git как прямую замену CVS, а затем представить другие изменения один за другим.

Answer 2

Взгляните на запись в блоге alblue на Gerrit

Это показывает рабочий процесс, отличный от классического централизованного сервера, такого как CVS или SVN. Внешне это выглядит примерно так же, как при извлечении исходного кода с центрального сервера Git, но вы передаете свои коммиты на сервер Gerrit, который может скомпилировать и протестировать код, чтобы убедиться, что он работает, прежде чем в конечном итоге передать изменения на центральный сервер Git.

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

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

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