Как повторно инициализировать git голое хранилище, чтобы все файлы были снова опубликованы?

Question

Я работаю над сайтом и использую git для контроля версий. Я настроил сервер для тестирования, создал git голое хранилище и выдвинул основную ветку (git push staging master).

Я получил ошибку - я забыл установить разрешения для папки назначения должным образом. Я установил разрешения, попытался нажать еще раз ... но git сказал, что все было в курсе. Добавление флага -f не имеет никакого значения. Так что, поскольку это была бесплатная sh pu sh, я удалил голое репо, настроил его снова, и все заработало.

В конце концов, я создал новую ветку для функций, которые я собираюсь протестировать, прежде чем слиться с производственная отрасль. Затем я сделал несколько исправлений ошибок в производственной ветке, поэтому я перебрал тестовую ветку, чтобы сохранить эти исправления. И, наконец, я опубликовал его с git push staging new-branch.

Однако, это не сработало; некоторые изменения в обновленной базе new-branch не сделали это на удаленном сервере. Должно быть, я сделал что-то не так, поэтому мне лучше просто повторить все это снова ... о. Как и раньше, я не знаю, как это сделать.

Итак, как я могу заставить git перезагружать все файлы, не удаляя пустое хранилище и не конфигурируя его снова?

I также попытался git push staging new-branch --delete и затем повторил его, но после этого отсутствующие коммиты все еще отсутствовали.

РЕДАКТИРОВАТЬ:

Удаленная ветвь, на которую я нажимаю, была создана с git init --bare и его hooks/post-receive настроен на:

#!/bin/sh
git --work-tree=/var/www/html --git-dir=/home/<nu_username>/repo/site.git checkout -f

РЕДАКТИРОВАТЬ 2:

Я думаю, что наконец-то начал понимать, что для большинства очевидно : (ab) использование git для публикации - фактически двухэтапный процесс. Сначала вносятся изменения, а затем проверяется репо. Я всегда думал об этом как об одном действии, не понимая, что происходит на самом деле.

Итак, в обеих описанных мной ситуациях изменения были успешно продвинуты. Проблема всегда была с оформлением заказа.

В ситуации 1 права репо были установлены правильно, поэтому изменения были перенесены правильно. Поскольку репо было актуальным, дальнейшие попытки pu sh не вызовут ловушку после получения.

В ситуации 2 изменения new-branch были переданы правильно, но ветвь фактически проверено было master. Кроме того, я не выдвинул последние коммиты master.

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

Это все, следовательно, вызвало из-за огромного недопонимания того, что на самом деле происходило между моим письмом git push и файлами, появляющимися на сервере.

Answer 1

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

В частности:

• Git не publi sh вещи. Git делает, хранит и манипулирует коммитами через базу данных Git объектов . Коммиты хранят файлы в единицах целого коммита: у вас либо коммит (у которого есть снимок всех его файлов), либо у вас нет коммита.

• Git никогда не отправляет файлы . Git толкает фиксирует .

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

Существует два распространенных способа вкручивания Git в систему развертывания:

• set receive.denyCurrentBranch до updateInstead с не-пустым хранилищем или
• с помощью перехвата после получения, чтобы сделать git --work-tree=<path> checkout -f с пустым хранилищем.

Вы упомянули «голый репозиторий» как в заголовке, так и в теле, так что, возможно, вы настроили хук после получения, подобный этому. Если так:

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

2. Помните что вы теперь (ab?) используете Git index , чтобы индексировать / кэшировать путь --work-tree. Существует только один индекс, поэтому он работает только с одним рабочим деревом.

3. Помните, что git checkout -f проверяет текущую ветвь . Это действительно имеет смысл, только если git push действительно обновило имя этой конкретной ветки (но, как правило, в большинстве случаев должно быть безвредным). Пустой репозиторий имеет текущую ветку, как и любой репозиторий. Он также имеет индекс, который немного странный, но похож на любой репозиторий. Индекс индексирует и кэширует рабочее дерево. Пустой репозиторий не имеет рабочего дерева, поэтому странно иметь индекс ... но в git checkout вы его временно настраиваете (на время этой одной команды git checkout ) с рабочим деревом. Так что это дерево работы, которое этот индекс индексирует / кэширует. В дальнейшем git checkout лучше использовать тот же путь, иначе индекс будет индексировать неверное рабочее дерево.

   В пустом хранилище текущая ветвь обычно начинается с master и обычно остается master. Таким образом, коммит, который вы проверите, является коммитом master. Добавление новых имен веток и / или изменение того, какие коммиты идентифицируют другие имена ветвей, не имеет никакого эффекта, пока имя master все еще идентифицирует тот же коммит.

4. Если вы ' используя какую-то другую команду - или git checkout -f с другими аргументами - задайте это в своем вопросе; нам нужно увидеть это, прежде чем мы сможем помочь.

Если индекс не совпадает c с фактическим рабочим деревом - что может произойти, если другие вещи, такие как сам ваш веб-сервер, манипулирует файлами в рабочем дереве - git checkout может работать не совсем так, как вы хотели бы. Лично я считаю, что правильным подходом является , а не попытка использовать Git в качестве системы развертывания, но у меня нет никаких рекомендаций относительно того, что до также использует.