Почему git am оставляет измененные файлы валяться? Как я могу адаптировать свой рабочий процесс, чтобы сделать лучше? - PullRequest
Новая
       38

Почему git am оставляет измененные файлы валяться? Как я могу адаптировать свой рабочий процесс, чтобы сделать лучше?

6 голосов
/ 28 апреля 2009

Это будет долго, но я надеюсь, что вы можете терпеть меня.

Я пытаюсь использовать git, чтобы поставить исходный код моей команды под контроль версий. После попытки найти разные подходы, которые будут работать для меня, я, наконец, решил использовать функцию git format-patch. FWIW, продукт представляет собой веб-приложение ASP.NET, работающее в Windows, и в настоящее время я использую msysgit .

Справочная информация:
У меня есть промежуточный сервер (зеркальный рабочий сервер), который содержит все файлы ASPX. Затем я создал git-репо, используя init-db внутри своей корневой папки, и сделал git add . для отслеживания всех файлов.

Чтобы у меня была локальная копия на моем ноутбуке, я фактически заархивировал папку «.git» с промежуточного сервера и отправил ее по FTP на свою локальную машину. Переименовал его в «staging.git» и сделал git clone staging.git webappfolder, чтобы выполнить мою разработку против.

После 2 коммитов для feature1 и feature2, пришло время применить изменения обратно к промежуточному серверу. Я сделал git format-patch -2, который выводит в файлы 0001blah.patch и 0002blah.patch.

Эти 2 файла исправлений затем отправляются на промежуточный сервер, и я сделал git am 0001blah.patch на самом промежуточном сервере. Выполнение git log показывает, что коммит прошел. Но когда я делаю git status, он показывает Changed but not updated: modified: file1.aspx.

Что это значит точно? Я также попытался сделать git apply 0001blah.patch, но все, что я получил, было error" patch failed: file1.aspx: patch does not apply.

Есть ли проблема с моим рабочим процессом? Любое понимание относительно правильного способа или помощи было бы чрезвычайно полезно. Опять же, модель исправлений была бы наиболее приемлемой для нас сейчас, поскольку мы не будем настраивать SSH-сервер в ближайшее время.

Ответы [ 2 ]

5 голосов
/ 28 апреля 2009

Я только что попробовал это: 

rm -rf clone?

# clone 1 is the working copy
mkdir clone1
(
    cd clone1
    git init
    echo foo >> file1
    git add file1
    git commit -m "Initial state"
)

# clone 2 is the staging repo
git clone clone1 clone2

# create patches
(
    cd clone1
    git tag staging # tag to track what's in staging

    echo feature1 >> file1
    git add file1
    git commit -m "Feature 1"

    echo feature2 >> file1
    git add file1
    git commit -m "Feature 2"

    rm *.patch
    git format-patch staging
)

# apply patches
(
    cd clone2
    git am ../clone1/*.patch
    # Cygwin/msysgit line ending weirdness when patching. Aborting and
    # reapplying clears it up.
    git am --abort 
    git am ../clone1/*.patch
    git log
    git status
)

Имеет небольшую проблему с тем, что патчи не применяются явно без двойного использования am, но я получаю чистый рабочий каталог в клоне 2 с правильным содержимым файла1. Так что, похоже, нет ничего плохого в вашем рабочем процессе как таковом.

Git apply только обновит рабочее дерево, но не выполнит коммит.

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

Для инкрементных обновлений промежуточной среды просто используйте git tag staging в ветке релиза, «git diff staging..HEAD> update.patch» для отправки по электронной почте, и стандартный unix «patch -p1» для его применения должен работать , Это если вам не нужно физически хранить историю изменений на промежуточном сервере.

3 голосов
/ 28 апреля 2009

Вы пробовали 

git am -3

? Из git-am doc , 

-3
--3way

When the patch does not apply cleanly, fall back on 3-way merge

Примечание. Начиная с Git, Google Summer of Code 2009 , существует проект "Научить git-применять трехстороннее резервное слияние git-am знает":

Когда git-apply исправляет файлы, файлы могут исправляться некорректно. В таком случае git-apply в настоящее время отклоняет патч.
Если он вызывается из git-am, то выполняется трехстороннее объединение:

  • получение данных "index ..." из патча и
  • построение временного дерева,
  • применив к этому патч, затем
  • объединение временного дерева с текущей веткой.

По разным причинам было бы неплохо выполнить весь танец временного дерева непосредственно внутри git-apply, так как это может быть полезно, скажем, команда «apply» git-sequence, ускорить обработку git-am, поменьше разветвляясь, и т. 1031 *

...