Использование git в качестве центрального хранилища

Question

Я настроил git для своего собственного использования - так что я могу получить доступ к проекту из «где угодно» и сохранить безопасность версий, если мне довелось работать над частью X здесь и частью Y здесь, и я могу объединиться при необходимости.

Однако только одна из моих машин для разработки имеет статический IP-адрес. Мой мозг застрял в режиме CVS, поэтому я попытался настроить git, чтобы эта машина была «центральным» сервером, с которого все остальные тянут.

Такого рода работы. У меня есть куча машин переменного тока, которые делают git-pull от 'master' M. Они делают git push для отправки данных обратно.

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

git reset --hard HEAD

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

Что-то в моей ментальной модели далеко. Помогите?

Answer 1

Вы хотите, чтобы ваш центральный репозиторий был пустым. Скажем, машина, на которой она живет, называется static:

$ ssh static git init --bare /git/myproject.git

Этот голый репозиторий является центральной точкой встречи: он предназначен для того, чтобы подталкивать, а не развивать.

Делайте ваши разработки на клонах центрального хранилища:

$ cd ~/src
$ git clone static:/git/myproject.git

Даже если вы находитесь на static , работайте в клоне:

$ git clone /git/myproject.git

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

Например:

$ git checkout -b fix-bug-in-foo
$ hack
$ git add file.c file.h
$ git commit -m "Fix ..."

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

Может быть, вы идете домой в ту ночь и добавили новую функцию. На следующее утро ты

$ git checkout master
$ git pull

обновить ваш локальный мастер, чтобы отразить, что находится в центральном хранилище.

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

$ git checkout fix-bug-in-foo
$ git rebase master

Команда rebase заставляет ваш репозиторий выглядеть так, как будто вы исправили ошибку foo поверх новой функции прошлой ночи. (Это похоже на svn update , но более гибкое и мощное.)

Теперь, чтобы получить это в вашем центральном мастере:

$ git checkout master
$ git merge fix-bug-in-foo
$ git push origin master

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

Answer 2

Если у вас есть центральный сервер с центральным хранилищем мерзавца, что хранилище должно быть bare хранилищем. Голые репозитории не имеют рабочих копий файлов в них. Следовательно, если вы работаете на этом центральном компьютере, вы работаете не с центральным репозиторием напрямую, а с локальным клоном.

Answer 3

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

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

$ ssh example.com
$ mkdir dotconf.git && cd dotconf.git
$ git init --bare
$ exit

Это создало пустой репо на сайте репо.

Теперь, если у меня уже есть локальный репо, я могу отправить его на удаленный сайт.

$ cd ~/src/dotconf

chdir в локальный каталог.

$ git remote add origin ssh://example.com/~/dotconf.git

Добавьте удаленное репо в качестве источника, так что push/pull будет действовать на это репо.

$ git push origin master

Переместите моего мастера к источнику (как ранее помечено через git remote). Теперь это удаленное репо считается моим «центральным репо». Все мои git push/pull будут взаимодействовать с источником.

Если я перейду к другому хосту, я могу легко вытащить с помощью клона репо в новое место.

$ git clone ssh://example.com/~/dotconf.git

Если я хочу заняться разработкой ПО на удаленном сервере, я сначала клонирую, а затем возвращаюсь в исходное хранилище.

$ cd ~/src
$ git clone ~/dotconf.git
$ cd ~/src/dotconf
  * do coding *
$ git push
  * check in from another location *
$ git pull

Скорее всего, вам придется установить свой git config --add branch.master.remote origin чтобы git pull не жаловался, что вы недостаточно конкретны. Другой альтернативой является установка главной ветки для --track удаленного источника. Полезно, если у вас есть несколько филиалов.

Answer 4

Я только что исследовал эту проблему сегодня. Этот блог пост имеет много дискуссий по этому вопросу, но , по мнению большинства , чтобы делать то , что сказал Манни. Посмотрите на комментарий к сообщению Дэвида Френча, чтобы узнать о некоторых других возможностях, в том числе о том, что делать, если в результате вы по ошибке нажмете на репозиторий, у которого есть незафиксированная работа в индексе или рабочем дереве. «git reset –soft HEAD ^» отменит внесенные изменения, не мешая вашей работе.