Ответ 1

Структура репозиториев не является вопросом, если сайты (что бы вы ни говорили с этим), а вопрос проектов.

Как правило:

• используйте ОДИН (голый, благословленный) репо для каждого независимого проекта
• если общие модули разделены, реализуйте с помощью submodules

В рамках каждого репо структурируйте работу с ветвями и не путайте ветки со средствами организации различного программного обеспечения стеки: ветки используются для организации работы в одном репо (т.е. разные строки разработки ОДНОГО программного обеспечения). Одна модель ветвления (которая, кажется, довольно популярна здесь в SO), такова:

Confused? Любопытно? Прочтите объяснение...

Ответ 2

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

Ответ 3

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

Если вы не выполняете кросс-платформенную разработку, установите auto crlf в false.

Управляйте ветвями таким образом:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Ответ 4

Вероятно, вы хотите иметь централизованный сервер, на который вы вносите изменения и клонируете. У этого сервера может быть один репозиторий или много. Я рекомендую читать http://sethrobertson.github.com/GitBestPractices/, который имеет несколько разделов, представляющих прямой интерес. В частности, выберите локальный рабочий процесс, распределенный рабочий процесс и как разделить вашу работу на репозитории.

Ответ 5

Основная настройка

Я предлагаю вам создать каталог, посвященный git на сервере.

Я использовал имя каталога /git на сервере, запущенном моей компанией для работы, и для личного использования я также создал каталог с именем /git на частном веб-сервере.

Внутри вашего / git каталога вы можете создать голые репозитории для своих проектов

ssh [email protected]
cd /git
mkdir Project7sName.git
cd Project7sName.git
git init --bare
echo "Take over the world project" > description

Добавить зрителя

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

Управление распределенной версией?

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

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

Используйте команды типа

git remote add siteA ssh://[email protected]/git/repositoryX.git

чтобы вы могли делать такие вещи, как

git push siteA master
git push siteB master

У меня есть резервная копия script, которая работает ежедневно, вытаскивая из github, из нашего собственного gitserver, накопителя NAS, USB-накопителя и нажав на каждый из них.

Таким образом, существует два метода обеспечения наличия нескольких копий изменения программного обеспечения.

• Пользователь (нажатие на несколько сайтов) и
• Администрацией (копирование изменений между сайтами).

Начните с настройки git на сервере и добавьте что-то вроде GitList для удобного просмотра изменений.

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

Импорт старых проектов?

Как системный администратор, вы можете импортировать старые проекты в Git.

Вы можете сделать это, выполнив пустой репозиторий.

git touch .gitignore
git add .gitignore
git commit -m Empty

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

rm *
unzip ...
git add *
git commit -m "Archived state 2013 week 18"
git tag ArchivedState2013week18

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

Кроме того, вы сможете использовать git blame, чтобы иметь представление о том, когда были введены некоторые строки кода.