Не удается скопировать папку на сервере, а затем отредактировать и нажать git?

Question

Раньше я использовал Mercurial (Hg), и было нормально делать что-то вроде на локальном ПК:

hg clone ssh://peter@hostingcompany.com/~/mysite.com

, а затем будет иметь локальную папку с именем mysite.com, и я могу отредактировать ее содержимое, зафиксировать и сказать hg push и отправить ее на сервер. Конечно, чтобы содержимое отображалось в «рабочем каталоге», мне нужно будет ssh и выполнить hg up.

С Git, если я делаю то же самое, на сервере, сделайте

git init
git add .
git commit -m "ok"

и на локальном ПК сделайте

git clone ssh://peter@hostingcompany.com/~/mysite.com

но если я отредактирую файл и git push ssh://peter@foo.com/~/mysite.com master, он откажется от него, потому что это не «голое хранилище».

Есть ли способ

1. В любом случае, нажмите Hg?
2. Или, что еще лучше, нажмите на него и сделайте так, чтобы оно автоматически делало что-то вроде hg up - это git checkout, чтобы контент сразу отображался на mysite.com (используя любой веб-браузер в любом месте).

---

Обновление:

Кажется, что обычной практикой является продвижение к голому репо ... но разве мы не можем использовать голое репо и заставить (2) работать выше? Если это практичный способ, то нам не нужно придерживаться правила «push to bare repo»?

Если есть какая-то другая причина, по-прежнему подталкивать к пустому репо и клонировать на сервере ... тогда:

если на сервере были такие каталоги, как ~/mysite.com и ~/other_folder и т. Д., То где должен находиться репозиторий для mysite.com? mysite.com - это содержимое сайта, поэтому, если я добавлю index.html, то любой браузер в мире сможет его увидеть. Так хорошо ли создавать пустое хранилище, разрешать клонирование ~/mysite.com с него и на локальном ПК автоматически использовать git push <path> master; ssh <path> "cd to that folder and do git checkout to update the content" по 1 строке на локальном ПК? Будет ли линия git push ssh://peter@hostingcompany.com/~/mysite.com master; ssh ssh://peter@hostingcompany.com/~/mysite.com 'git pull; git checkout'?

Answer 1

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

remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.

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

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

Answer 2

В Git, вы должны загружать только пустой репозиторий. Лучшее решение - создать пустой репозиторий на сервере, на который вы отправляете, а затем его непонятный клон, содержащий извлечение, поэтому после перехода в пустой репозиторий вы отправляете SSH на сервер и делаете git pull из репозитория non-bare (или настройте hook , чтобы сделать это автоматически после того, как репо голого получает новую версию).

Answer 3

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

git init . --bare

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

Answer 4

Git не поддерживает отправку на ветку, которая проверена на удаленном конце.

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

Итак, у вас есть два варианта:

1. Создайте пустой репозиторий (mysite.com.git) и не голый репозиторий (mysite.com). В голом хранилище добавьте post-update хук к git --git-dir=.../mysite.com pull

2. Создайте только один репозиторий и:

   1. Снять головку: git checkout master@{0}

   2. Добавьте post-update крючок к git merge master

   Причина в том, что git отказывается модифицировать извлеченную ветку, но если вы отмените ветку, вы сможете нажать. И вы сможете обновить рабочий каталог с помощью ловушки (ловушка - это скрипт, помещенный в каталог hooks в хранилище). Вы можете либо создать отдельную ветку и проверить это, либо использовать состояние «detached HEAD» (как предложено выше - git запоминает, какая ветка извлечена, имея специальную ссылку «HEAD», которая указывает на ветку, но если Вы извлекаете что-то, не являющееся ветвью, оно делается для того, чтобы указывать на ревизию напрямую, и это называется «отдельная ветвь», и поскольку ни одна ветвь не извлечена, вы можете перейти к любой из них). 1034 *

Answer 5

Вы должны передавать только в пустые хранилища (в пустом хранилище нет рабочей копии).

У вас есть два решения:

• вытащить из удаленного хранилища (тогда он попросит разрешения конфликтов)
• сделать ваш удаленный репозиторий пустым

РЕДАКТИРОВАТЬ мое предположение, что удаленное хранилище имеет локальные модификации, неверно; Я не знаю, почему вы не можете нажать, но остальная часть моего поста остается в силе: вы не должны нажимать на обычные репо.