Как я могу использовать Git и Git Extensions?

Question

Введение

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

Я хочу начать использовать Git, потому что у нас есть пара парней, которые работают вне офиса, и они жаловались, что иногда они не могут дозвониться до некоторых других систем контроля версий, потому что их интеграция с IDE заставляет их дуться и падают, когда они выходят из контакта. Идея Git «Каждый рабочий каталог - это хранилище», похоже, должна как-то решить эту проблему.

В любом случае, я скачал «Git Extensions», чтобы добавить The Shiny в контекстные меню Windows и т. Д., И обнаружил, что у меня действительно нет понятия о том, как я должен использовать это для управления версионностью. , Не найдя ничего очевидного после поиска в Google, я представляю следующий теоретический сценарий переполнения стека в надежде, что кто-то подскажет мне, что делать, маленькими словами:

Сценарий

У меня три проекта. Один проект, ProjectReuse, используется двумя другими проектами (ProjectA и ProjectB). Различные люди в организации должны будут редактировать код для каждого проекта, используя Visual Studio 2010.

У меня на рабочем столе три папки, помеченные как «ProjectReuse», «ProjectA» и «ProjectB». У меня открыто окно Git Extenstions. На меня смотрит корова в шляпе Санта-Клауса.

Вопросы

Что мне теперь делать, чтобы создавать репозитории таким образом, чтобы несколько человек (включая этих надоедливых парней, которые не всегда были на месте) могли получить доступ к репозиторию * , когда им это необходимо, на месте или выключен, с постоянным подключением к нашим серверам или без него?

Когда первому парню нужно отредактировать файл, что он должен сделать? Проверять, выписываться? Ветка? Я должен объяснить это другим членам команды, и сам немного колеблюсь в этих концепциях. Ранее я использовал только контроль версий для своих сольных проектов.

Уиллинг и оправдания

Первый "как мне это настроить?" вопрос в том, что меня больше всего интересует, но я полагаю, что если я собираюсь попросить руководство для идиота, я мог бы также попросить, чтобы оно было как можно более полезным для следующего идиота, который наткнется на этот вопрос. Я не ищу особо подробных ответов здесь; У меня просто нет ясного представления о том, как работает многопользовательская система контроля версий. Как только я это запомню, я смогу собрать все остальное самостоятельно.

Answer 1

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

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

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

Но, но как же я должен управлять командой разработчиков, как я слышал?Не бойся.Я сказал, что не было никакого центрального репозитория, но это не мешает вам назначить один из репозиториев как репозиторий релизов, а другой - как экспериментальный или как угодно.

Вам нужен рабочий процесс.Как правило, вы создаете указанное хранилище релизов, а затем говорите: «здесь все вытаскивают мастера».Это представляет ваш последний "стабильный" выпуск.Теперь вы говорите всем, чтобы перейти сюда и развивать их новые функции.Они делают это.Когда это будет сделано, вы попросите людей объединить свои изменения обратно в свой собственный мастер или куда-то еще, затем вы, менеджер по выпуску, извлечете их (возможно, в ветку разработки, но вы вполне могли бы сделать это в своем мастере выпуска, потому что это тривиальноотменить коммиты).Затем следующий человек обновляет своего мастера и выполняет их слияние.Они разрешают свои собственные конфликты слияний и т. Д. И т. Д., Пока у вас не появятся все необходимые функции.Вы проводите тестирование и т. Д., Тогда репозиторий выпусков действительно вытягивает все это в свой мастер.

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

Это работает.

Answer 2

Как сказали Ninefingers, просто запустите новый репозиторий и позвольте другим клонировать его. Имейте в виду, что если вам нужен публичный (или центральный) репозиторий, создайте общий репозиторий, а не частный репозиторий. Самый простой способ - сначала создать личный репозиторий, а затем клонировать его в место (например, сетевой ресурс), к которому у всех есть доступ в качестве общего репозитория.

Я создал несколько видеоуроков для Git Extensions здесь: http://code.google.com/p/gitextensions/ Видео уроки немного устарели и не очень хороши, так как у меня нет микрофона или навыков редактирования видео, но этого должно быть достаточно, чтобы вы начали.

Удачи!