Git Setup Лучшие практики - PullRequest
       2

Git Setup Лучшие практики

18 голосов
/ 14 февраля 2012

Мне было поручено настроить Git для моего офиса.У нас есть несколько сайтов.Я просто настроил сетевой диск, чтобы мы могли вносить в него изменения.Мой вопрос: где я могу инициализировать Git-репозиторий?

  1. Новый каталог + init для каждого сайта?
  2. Один инициализатор на чистом и новом диске, а каждый каталог - отдельный сайт?
  3. Что-то еще лучше, что мне не хватает?

Я обращаюсь за советом ко всем и каждому, особенно, если вы проклинали первого парня, который его задал, спрашивая "ПОЧЕМУ"?

Ответы [ 5 ]

40 голосов
/ 14 февраля 2012

Структура репо - это не вопрос сайтов (что вы хотите сказать с этим), а вопрос проектов .

Как правило,thumb:

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

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

enter image description here

Смущены?Любопытно?Прочитайте объяснение ...

4 голосов
/ 14 февраля 2012

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

2 голосов
/ 15 февраля 2012

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

Если вы не занимаетесь кроссплатформенной разработкой, установите для автоматического crlf значение false.

Управляйте своими ветками следующим образом:

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

1 голос
/ 30 ноября 2017

Базовая настройка

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

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

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

ssh git@myserver
cd /git
mkdir Project7sName.git
cd Project7sName.git
git init --bare
echo "Take over the world project" > description

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

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

GitList example image

Распределенный контроль версий?

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

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

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

git remote add siteA ssh://git@siteA/git/repositoryX.git

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

git push siteA master
git push siteB master

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

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

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

Начните с настройки 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, чтобы иметь представление, когда были введены некоторые строки кода.

1 голос
/ 15 февраля 2012

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...