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

Question

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

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

Предыстория:
У меня есть промежуточный сервер (mirrors production server), который содержит все aspx-файлы.Затем я создал репозиторий git, используя инициализация-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-сервер в ближайшее время.

Answer 1

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

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 с правильным содержимым file1.Таким образом, кажется, что в вашем рабочем процессе как таковом нет ничего плохого.

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

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

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

Answer 2

Вы пробовали a

git am -3 

?Из git-am док,

-3
--3way

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

---

Примечание:От Git Google Лето кода 2009, существует проект по "Обучению git-применению 3-стороннего резервного варианта слияния, который знает git-am".:

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

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

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