Git管理下のファイルの差分をpatchコマンドで適応するまとめ

たまに使うのですが、その度に調べたりしているのでまとめておきました。

確認version

  • Git 2.23.0

patchファイルを作成する

git diff

git diffの場合はシンプルです。今変更しているファイルの差分を出力するだけです。

$ git diff > file.patch
git log

git logの場合はそのままだと、リポジトリ全てのログが表示されてしまうのでリビジョン指定やファイル指定を行うことがほとんどです。

よく使うのは特定ファイルの直近コミットの差分、特定ファイルの指定コミットの差分ですね。

# fileの直近コミットの差分
$ git log -u -1 file > file.patch

# fileの指定コミットの差分
$ git log -u -1 {コミットのhash値} file > file.patch
no-prefixオプション

git diffやgit logはルートディレクトリからの相対パスにprefixをつけた状態でファイルパスを表示します。

--- a/file
+++ b/file

これが、patchコマンドで適応するときどう影響してくるかは後述しますがno-prefixオプションをつけるとこのprefixを無くすことができます。

--no-prefix
    Do not show any source or destination prefix.

実際にno-prefixオプションをつけてみると下記のように出力されます。

--- file
+++ file

patchファイルを適応する

patchファイルの適応にはpatchコマンドを使用します。

$ patch < file.patch

このコマンドを実行するパスが非常に大事になってきます。
git diffによって出力されたファイルパスをpatchコマンドを実行したパスを起点にファイルを探します。

この挙動をpオプションで制御することができます。

pオプション
-pnum  or  --strip=num
    Strip the smallest prefix containing num leading slashes from each file name found in the patch file.  A sequence of one or more adjacent slashes is counted as  a  single
    slash.   This  controls  how  file names found in the patch file are treated, in case you keep your files in a different directory than the person who sent out the patch.
    For example, supposing the file name in the patch file was

       /u/howard/src/blurfl/blurfl.c

    setting -p0 gives the entire file name unmodified, -p1 gives

       u/howard/src/blurfl/blurfl.c

    without the leading slash, -p4 gives

       blurfl/blurfl.c

    and not specifying -p at all just gives you blurfl.c.  Whatever you end up with is looked for either in the current directory,  or  the  directory  specified  by  the  -d
    option.

ヘルプに記載されている通りですが要約すると下記のようになるかと思います。

  • オプションが指定されていない場合はファイル名のみ
  • 0を指定するとルートディレクトリからの相対パス
  • 0以外の数字を指定すると、指定した数分のスラッシュまでを削る

なので、ルートディレクトリでpatchコマンドを実行する際は-p0をつけるとよいのですが、
先述のno-prefixオプションを使っていない場合には実際のパスには存在しないa/,b/が付与されているので-p0を使いたい場合にはno-prefixをつけようということです。
no-prefixをつけない場合には-p1をつけてa/,b/を無視すればよいので、要はどっちで考慮するかということです。

# ルートディレクトリでno-prefixをつけて出力
$ git diff --no-prefix > file.patch # patch出力
$ git checkout . # 変更を元に戻す
$ patch -p0 < file.patch # 変更を適応する

# ルートディレクトリでno-prefixをつけないで出力
$ git diff > file.patch # patch出力
$ git checkout . # 変更を元に戻す
$ patch -p1 < file.patch # 変更を適応する

たとえ、間違えてもpatchコマンドはファイルが見つからないときに、下記プロンプトが出てカレントディレクトリからのパスを記載すれば適応してくれます。

File to patch: 

適応した変更を元に戻す

patchコマンドのRオプションを使えばできます。

$ patch -R < file.patch

Gitで管理されているファイルでこんなことをやっても、なんも面白くないですが
例えばサーバ上はGit管理されていなくて、同じディレクトリ構成のローカル環境がGitで管理されている場合などに
patchファイル作成して適応すれば便利かもしれません。

git-svn利用時SubversionのリポジトリURLが変更になった時の対応

git svn 環境でのリポジトリ再配置 ( svn switch --relocate に代わる何か ) - do_aki's log
上記URLの情報を最初に見つけて最終的にはGitオフィシャルのWikiにたどり着いた。

  • Edit the svn-remote url URL in .git/config to point to the new domain name
  • Run git svn fetch - This needs to fetch at least one new revision from svn!
  • Change svn-remote url back to the original url
  • Run git svn rebase -l to do a local rebase (with the changes that came in with the last fetch operation)
  • Change svn-remote url back to the new url
  • Run git svn rebase should now work again!

This will only work, if the git svn fetch step actually fetches anything! (Took me a while to discover that... I had to put in a dummy revision to our svn repository to make it happen!)

GitSvnSwitch - Git SCM Wiki
  1. .git/configを編集してsvn-remote urlを新URLに変更
  2. git svn fetch
  3. .git/configを編集してsvn-remote urlを旧URLに変更
  4. git svn rebase -l
    • オプションlは--localの略。fetchしてある情報からrebaseするということだと思うがなんで実行前に元のリポジトリURLに戻す必要があるのか。
  5. .git/configを編集してsvn -remote urlを新URLに変更
  6. git svn rebaseが動作するようになる!

これが動作するのはgit svn fetchで何らかの変更を取得できた時のみである(それを発見するのに時間がかかった。私はダミーのリビジョンをでそれを実現した。)
ようするにgit svn fetchで何らかの変更を取得しないと成功しないみたいだから、svn側で何でもいいからコミット作ってリビジョンを進めるといいみたいね。

Git-Flowとpull rebaseって相性悪くないですか?

Git-FlowはA successful Git branching modelを補助するツールで原則ブランチのマージはno-ffマージが行われるんだけど、いざマージしてpushしようとしたら他の誰かが更新していてpullしなければならない場合がある。
リモートブランチとの3点マージはしたくないので(ここがA successful Git branching modelと噛み合ってないのかも)pull rebaseをするんだけど、そうするとマージコミットが消滅してしまってなんのためにフューチャーブランチきってno-ffマージしたんだ...となってしまっている。

この悩みに対する解は現在無い

2014/12/29追記

  • rオプションが良さそう。調べてみましょう。

まとめ

  • git flow feature finishする時は-kするとフィーチャーブランチが消えない
  • git flow feature finishする時に-rするとフィーチャーブランチ上でrebaseした上で--no-ffなマージを行ってくれる
  • この2つを覚えておけばフィーチャーブランチの再現をしなくて済んでハッピー
git flow feature finishした後にリモート更新で気づくと悲しい問題への対処法 - cynipeと読む