git am PATCH 失敗的處理方法

參考：http://www.cnblogs.com/domainfei/articles/2433504.html

http://blog.sina.com.cn/s/blog_5372b1a301015y0n.html

英文原文地址：http://www.pizzhacks.com/bugdrome/2011/10/deal-with-git-am-failures/

比如，一個典型的git am失敗，可能是這樣的：

$ git am PATCH

Applying: PACTH DESCRIPTION

error: patch failed: file.c:137

error: file.c: patch does not apply

error: patch failed: Makefile:24

error: libavfilter/Makefile: patch does not apply

Patch failed at 0001 PATCH DESCRIPTION

When you have resolved this problem run "git am --resolved".

If you would prefer to skip this patch, instead run "git am --skip".

To restore the original branch and stop patching run "git am --abort".

正如你所見，如果衝突發生，git只是輸出上述信息，然後就停下來。一個小衝突會導致整個patch都不會被集成。

處理這種問題的最簡單方法是先使用 git am --abort，然後手動的添加此patch, patch -p1 < PATCH，手動解決掉代碼衝突，最後使用 git commit -a 提交代碼。但是這樣做有個問題就是你會失去PATCH中原本包含的commit信息（比如From，Date，Subject，Signed-off-by等）。應該有一種更聰明的方法。

在 .git/rebase-apply 目錄下，存放着相應的補丁文件，名字是“0001” （在更新的git版本中，存放補丁文件的目錄名有所改變，這裏使用的git版本是 1.7.4.1）。

事實上，你可以使用 git apply 命令打patch（git apply 是git中的patch命令）。如同使用 patch -p1 命令時一樣，然後手動解決代碼衝突（檢視生成的 .rej 文件，與衝突文件比較，修改衝突內容，並最終把文件加入到index中）：

$ git apply PATCH --reject

$ edit edit edit

（譯註：根據.rej文件手動解決所有衝突）

$ git add FIXED_FILES

$ git am --resolved

就這麼簡單！

想多一些解釋，好吧。git am 並不改變index，你需要使用 git apply --reject 打patch（保存在 .git/rebase-apply），手動解決代碼衝突，（譯註：使用 git status 列出所有涉及文件），把所有文件（不僅僅是引起衝突的文件）添加到（git add）index，最後告訴 git am 你已經解決（--resolved）了問題。這樣做的好處是你不需要重新編輯commit信息。而且，如果你正在打的是一系列patch（就是說你在打的是多個patch，比如 git am *.patch）你不需要使用 git am --abort，然後又 git am。

新手剛剛開始接觸 Git，爲了維護核心倉庫的“純潔”，避免太多無關信息被誤提交進倉庫（再次批評一些圖形化工具默認的“Select All”），採用了核心倉庫只讀，郵件提交 patch，審覈後再提交的工作流程。

期間有時會遇到合併衝突，正常的原因一般是未及時下載新版本產生了衝突，特殊一點的原因是手工修改 patch 內容導致的。有時候看註釋寫得不夠準確，忍不住就改了，有時候是 Geany 保存時自動去除了 patch 原文中的行尾空格，有時候是文件回車格式、BOM 等變動了，總之合併 patch 的時候，如果生成 patch 的“原稿”找不到，一般就產生了衝突，比如：

$ git am 0001-BUG-Sybase.patch
Applying: CHG: 讀取Sybase如果時間爲空,設置默認時間的修改
error: patch failed: source.php:38
error: source.php: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".


剛開始一看有些懵，因爲沒有任何衝突在哪裏的提示，後來找到一種方法，am 操作出問題後先手工 apply：

$ git apply --reject 0001-BUG-Sybase.patch
Checking patch source.php...
error: while searching for:
// 註釋
// 以下爲幾行代碼片斷
error: patch failed: source.php:38
Applying patch source.php with 1 rejects...
Rejected hunk #1.


這樣，就把沒有衝突的文件先合併了，剩下有衝突的作了標記。先看輸出，error: while searching for: 說明是這段代碼有衝突，error: patch failed: source.php:38 指明瞭產生衝突的代碼片斷的開始行號，相應的，patch 中應該有這麼一段：

diff --git a/source.php b/source.php
index 8770441..4e77b8a 100644
--- a/source.php
+++ b/source.php
@@ -38,27 +38,23 @@ class Site extends Module
// 註釋
// 以下爲幾行代碼片斷


同時，還會產生一個 source.php.rej 文件，裏面也是上面這段因爲衝突無法合併的代碼片斷。

現在，在這段代碼中查找衝突原因，並對文件進行修改，source.php.rej 參考完了可以刪掉。改好之後，用 git add 把 source.php 添加到緩衝區，同時也要把其他沒有衝突合併成功了的文件也加進來，因爲在作 apply 操作的時候他們也發生了變化：

$ git add source.php
$ git add 其他 apply 進來的文件們


最後：

$ git am --resolved
Applying: CHG: 讀取Sybase如果時間爲空,設置默認時間的修改


大功告成。

中間如果處理亂了，用 git reset 恢復即可，所以合併 patch 在一個“乾淨”的分支上處理更好。