git-rebase - Reapply commits on top of another base tipgit-rebase - 別のベースチップの上にコミットを再適用する


git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
	[<upstream> [<branch>]]
git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
	--root [<branch>]
git rebase --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch


If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current branch.<branch>が指定された場合、git rebasegit checkout <branch>他のことをする前に自動を実行します。そうでなければ、現在のブランチに残ります。

If <upstream> is not specified, the upstream configured in branch.<name>.remote and branch.<name>.merge options will be used (see git-config[1] for details) and the --fork-point option is assumed. If you are currently not on any branch or if the current branch does not have a configured upstream, the rebase will abort.<upstream>が指定されていない場合、branch。<name> .remoteおよびbranch。<name> .mergeオプションで設定されているアップストリームが使用され(詳細はgit-config [1]を参照)、--fork-pointオプションが想定されます。現在どのブランチにもいない場合、または現在のブランチにアップストリームが設定されていない場合は、リベースは中止されます。

All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD; or by git log 'fork_point'..HEAD, if --fork-point is active (see the description on --fork-point below); or by git log HEAD, if the --root option is specified.現在のブランチでコミットされているが<アップストリーム>にはないコミットによるすべての変更は一時領域に保存されます。これはで表示されるのと同じコミットのセットgit log <upstream>..HEADです。アクティブgit log 'fork_point'..HEADであれば、またはによって--fork-point(下記の説明を--fork-point参照)。オプションが指定されてgit log HEADいる--root場合はby 。

The current branch is reset to <upstream>, or <newbase> if the --onto option was supplied. This has the exact same effect as git reset --hard <upstream> (or <newbase>). ORIG_HEAD is set to point at the tip of the branch before the reset.現在のブランチは<upstream>、または--ontoオプションが指定されている場合は<newbase>にリセットされます。これはgit reset --hard <upstream>(または<newbase>)とまったく同じ効果があります。ORIG_HEADは、リセット前に分岐の先端を指すように設定されています。

The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).以前に一時領域に保存されたコミットは、現在のブランチに順番に1つずつ再適用されます。HEADでのコミットと同じテキスト上の変更を導入するHEADでのコミットは省略されていることに注意してください(つまり、別のコミットメッセージまたはタイムスタンプを持つアップストリームで既に受け入れられたパッチはスキップされます)。

It is possible that a merge failure will prevent this process from being completely automatic. You will have to resolve any such merge failure and run git rebase --continue. Another option is to bypass the commit that caused the merge failure with git rebase --skip. To check out the original <branch> and remove the .git/rebase-apply working files, use the command git rebase --abort instead.マージが失敗すると、このプロセスが完全に自動化されなくなる可能性があります。このようなマージの失敗を解決して実行する必要がありますgit rebase --continue。別の選択肢は、マージ失敗の原因となったコミットを回避することですgit rebase --skip。元の<branch>をチェックアウトして.git / rebase-apply作業ファイルを削除するには、git rebase --abort代わりにこのコマンドを使用してください。

Assume the following history exists and the current branch is "topic":以下の履歴が存在し、現在のブランチが "topic"であると仮定します。

          A---B---C topic
    D---E---F---G master

From this point, the result of either of the following commands:この時点から、以下のいずれかのコマンドの結果。

git rebase master
git rebase master topic

would be:だろう:

                  A'--B'--C' topic
    D---E---F---G master

NOTE: The latter form is just a short-hand of git checkout topic followed by git rebase master. When rebase exits topic will remain the checked-out branch.注:後者の形態は、のわずか手でgit checkout topic続きますgit rebase master。リベース出口topicがチェックアウトされたブランチのままになります。

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped. For example, running git rebase master on the following history (in which A' and A introduce the same set of changes, but have different committer information):上流のブランチにすでに行った変更が含まれている場合(例えば、上流で適用されたパッチを郵送したためなど)、そのコミットはスキップされます。たとえば、実行しているgit rebase master(ここで、次の履歴にA'A変化の同じセットをご紹介しますが、別のコミッターの情報を持っています):

          A---B---C topic
    D---E---A'---F master

will result in:結果は次のようになります。

                   B'---C' topic
    D---E---A'---F master

Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using rebase --onto.これを使用して、トピックブランチをあるブランチから別のブランチに移植し、トピックブランチを後者のブランチから分岐したように見せかけることができますrebase --onto

First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.まずあなたのトピック次にブランチに基づいていると仮定しましょう。例えば、トピックで開発された機能は、次に見られるいくつかの機能に依存します。

    o---o---o---o---o  master
          o---o---o---o---o  next
                            o---o---o  topic

We want to make topic forked from branch master; for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:ブランチマスターから話題を分岐させたい。たとえば、トピックが依存する機能がより安定したマスターブランチに統合されたためです。ツリーをこのようにします。

    o---o---o---o---o  master
        |            \
        |             o'--o'--o'  topic
          o---o---o---o---o  next

We can get this using the following command:これは、次のコマンドを使って取得できます。

git rebase --onto master next topic

Another example of --onto option is to rebase part of a branch. If we have the following situation:--ontoオプションのもう一つの例は、ブランチの一部をリベースすることです。次のような状況にあるとします。

                            H---I---J topicB
                  E---F---G  topicA
    A---B---C---D  master

then the commandそれからコマンド

git rebase --onto master topicA topicB

would result in:次のようになります。

                 H'--I'--J'  topicB
                | E---F---G  topicA
    A---B---C---D  master

This is useful when topicB does not depend on topicA.これは、topicBがtopicAに依存しない場合に便利です。

A range of commits could also be removed with rebase. If we have the following situation:コミットの範囲もリベースで削除することができます。次のような状況にあるとします。

    E---F---G---H---I---J  topicA

then the commandそれからコマンド

git rebase --onto topicA~5 topicA~3 topicA

would result in the removal of commits F and G:FとGのコミットが削除されます。

    E---H'---I'---J'  topicA

This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to --onto and the <upstream> parameter can be any valid commit-ish.これは、FとGに何らかの欠陥がある場合、またはtopicAの一部にすべきでない場合に便利です。--ontoと<upstream>パラメータへの引数は、任意の有効なcommit-ishにすることができます。

In case of conflict, git rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers (<<<<<<) and make edits to resolve the conflict. For each file you edit, you need to tell Git that the conflict has been resolved, typically this would be done with衝突が発生した場合、git rebaseは最初の問題のあるコミットで停止し、ツリーに衝突マーカーを残します。git diffを使ってマーカーを探し(<<<<<<)、競合を解消するために編集することができます。編集したファイルごとに、競合が解決されたことをGitに伝える必要があります。通常これは

git add <filename>

After resolving the conflict manually and updating the index with the desired resolution, you can continue the rebasing process with手動で競合を解決し、目的の解決方法でインデックスを更新したら、次の手順でリベース処理を続行できます。

git rebase --continue

Alternatively, you can undo the git rebase withあるいは、git rebaseを元に戻すことができます。

git rebase --abort



Set to false to use the legacy shellscript implementation of git-rebase[1]. Is true by default, which means use the built-in rewrite of it in C.git-rebase [1]falseのレガシーシェルスクリプト実装を使用するように設定します。これはデフォルトであり、これはCの組み込み式の書き換えを使用することを意味します。true

The C rewrite is first included with Git version 2.20. This option serves an an escape hatch to re-enable the legacy version in case any bugs are found in the rewrite. This option and the shellscript version of git-rebase[1] will be removed in some future release.Cの書き換えはGitバージョン2.20に最初に含まれています。このオプションは、書き換えにバグが見つかった場合にレガシーバージョンを再度有効にするためのエスケープハッチとして機能します。このオプションとgit-rebase [1]のshellscript版は将来のリリースで削除される予定です。

If you find some reason to set this option to false other than one-off testing you should report the behavior difference as a bug in git.このオプションをfalse1回限りのテスト以外に設定する理由が見つかった場合は、動作の違いをgitのバグとして報告してください。


Whether to show a diffstat of what changed upstream since the last rebase. False by default.最後のリベース以降、アップストリームで何が変更されたかのdiffstatを表示するかどうか。デフォルトではfalseです。


If set to true enable --autosquash option by default.trueに設定した--autosquash場合、デフォルトでオプションが有効になります。


When set to true, automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts. This option can be overridden by the --no-autostash and --autostash options of git-rebase[1]. Defaults to false.trueに設定すると、操作が始まる前に一時的な隠し場所エントリが自動的に作成され、操作が終了した後でそれが適用されます。これは、汚れた作業ツリーでrebaseを実行できることを意味します。ただし、慎重に使用してください。リベースが成功した後の最後のstashアプリケーションは、重要な衝突を引き起こす可能性があります。このオプションはgit-rebase [1]--no-autostashand --autostashオプションで上書きすることができます。デフォルトはfalseです。


If set to "warn", git rebase -i will print a warning if some commits are removed (e.g. a line was deleted), however the rebase will still proceed. If set to "error", it will print the previous warning and stop the rebase, git rebase --edit-todo can then be used to correct the error. If set to "ignore", no checking is done. To drop a commit without warning or error, use the drop command in the todo list. Defaults to "ignore"."warn"に設定すると、git rebase -iはいくつかのコミットが削除された(例えば、行が削除された)場合に警告を表示しますが、それでもリベースは進行します。"error"に設定すると、前の警告を表示してリベースを停止し、git rebase --edit-todoを使用してエラーを修正できます。「無視」に設定すると、チェックは行われません。警告やエラーを表示せずにコミットを中止するにdropは、作業リストのコマンドを使用します。デフォルトは "ignore"です。


A format string, as specified in git-log[1], to be used for the todo list during an interactive rebase. The format will automatically have the long commit hash prepended to the format.git-log [1]で指定されているフォーマット文字列。対話的なリベースの際にToDoリストに使用されます。フォーマットは自動的にロングコミットハッシュをフォーマットの先頭に追加します。


If set to true, git rebase will use abbreviated command names in the todo list resulting in something like this:trueに設定されてgit rebaseいると、ToDoリストで短縮されたコマンド名が使用され、次のようになります。

	p deadbee The oneline of the commit
	p fa1afe1 The oneline of the next commit

instead of:の代わりに:

	pick deadbee The oneline of the commit
	pick fa1afe1 The oneline of the next commit

Defaults to false.デフォルトはfalseです。


Automatically reschedule exec commands that failed. This only makes sense in interactive mode (or when an --exec option was provided). This is the same as specifying the --reschedule-failed-exec option.exec失敗したコマンドを自動的に再スケジュールします。これは対話モード(または--execオプションが提供されたとき)でのみ意味があります。これは--reschedule-failed-execオプションを指定するのと同じです。


--onto <newbase>

Starting point at which to create the new commits. If the --onto option is not specified, the starting point is <upstream>. May be any valid commit, and not just an existing branch name.新しいコミットを作成する開始点。--ontoオプションが指定されていない場合、開始点は<upstream>です。既存のブランチ名だけでなく、任意の有効なコミットである可能性があります。

As a special case, you may use "A...B" as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.特別な場合として、マージベースが1つだけある場合は、AとBのマージベースのショートカットとして "A ... B"を使用できます。あなたはせいぜいAとBの一方を除外することができます、その場合それはデフォルトでHEADになります。

<upstream> <上流>

Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch.比較する上流ブランチ。既存のブランチ名だけでなく、任意の有効なコミットである可能性があります。現在のブランチに設定されているアップストリームがデフォルトになります。

<branch> <分岐>

Working branch; defaults to HEAD.作業ブランチ デフォルトはHEADです。

--continue - 持続する

Restart the rebasing process after having resolved a merge conflict.マージの競合を解決したら、リベースプロセスを再開します。

--abort - アボート

Abort the rebase operation and reset HEAD to the original branch. If <branch> was provided when the rebase operation was started, then HEAD will be reset to <branch>. Otherwise HEAD will be reset to where it was when the rebase operation was started.リベース操作を中止して、HEADを元のブランチにリセットします。リベース操作の開始時に<branch>が指定された場合、HEADは<branch>にリセットされます。それ以外の場合、HEADはリベース操作が開始されたときの位置にリセットされます。

--quit - 終了する

Abort the rebase operation but HEAD is not reset back to the original branch. The index and working tree are also left unchanged as a result.リベース操作を中止しますが、HEADは元のブランチにリセットされません。その結果、インデックスと作業ツリーも変更されません。


Keep the commits that do not change anything from its parents in the result.結果にその親から何も変わらないコミットを保管してください。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。


By default, rebasing commits with an empty message will fail. This option overrides that behavior, allowing commits with empty messages to be rebased.デフォルトでは、空のメッセージでコミットをリベースすると失敗します。このオプションはその振る舞いを上書きし、空のメッセージを含むコミットをリベースすることを可能にします。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

--skip - スキップ

Restart the rebasing process by skipping the current patch.現在のパッチをスキップして、リベースプロセスを再開します。


Edit the todo list during an interactive rebase.対話的なリベース中に仕事リストを編集します。


Show the current patch in an interactive rebase or when rebase is stopped because of conflicts. This is the equivalent of git show REBASE_HEAD.対話式リベースで、または競合のためにリベースが停止されたときに現在のパッチを表示します。これはと同等ですgit show REBASE_HEAD

--merge - マージ

Use merging strategies to rebase. When the recursive (default) merge strategy is used, this allows rebase to be aware of renames on the upstream side.リベースするためにマージ戦略を使用してください。再帰的(デフォルト)マージ戦略が使用されるとき、これはrebaseが上流側の名前変更を認識することを可能にします。

Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.リベースマージは、作業ブランチから各コミットを<upstream>ブランチの上に再生することによって機能します。このため、マージの競合が発生したときに、私たちのものとして報告されているのは<upstream>から始まるこれまでのリベース系列であり、それらはワーキングブランチです。言い換えれば、両側が入れ替わっています。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

-s <strategy> -s <戦略>
--strategy=<strategy> --strategy = <strategy>

Use the given merge strategy. If there is no -s option git merge-recursive is used instead. This implies --merge.与えられたマージ戦略を使います。-sオプションがない場合は、代わりにgit merge-recursiveが使用されます。これは--mergeを意味します。

Because git rebase replays each commit from the working branch on top of the <upstream> branch using the given strategy, using the ours strategy simply empties all patches from the <branch>, which makes little sense.git rebaseは与えられたストラテジーを使って<upstream>ブランチの上にある作業ブランチからコミットをそれぞれ再生するので、oursストラテジーを使うことは単に<branch>からすべてのパッチを空にします。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

-X <strategy-option> -X <戦略オプション>
--strategy-option=<strategy-option> --strategy-option = <strategy-option>

Pass the <strategy-option> through to the merge strategy. This implies --merge and, if no strategy has been specified, -s recursive. Note the reversal of ours and theirs as noted above for the -m option.<strategy-option>をマージ戦略に渡します。これが意味--mergeします、そして、戦略が指定されていないなら、-s recursive。オプションのために上で注意されるように私たち彼らものの逆転に注意してください-m

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

-S[<keyid>] -S [<keyid>]
--gpg-sign[=<keyid>] --gpg-sign [= <keyid>]

GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space.GPG-signがコミットします。keyid引数はコミッターのアイデンティティオプションで、デフォルトです。指定した場合は、スペースなしでオプションに固定する必要があります。

--quiet - 静か

Be quiet. Implies --no-stat.静かにして。--no-statを意味します。

--verbose - 冗談

Be verbose. Implies --stat.冗長になります。暗黙のうちに--stat。

--stat - スタット

Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase.stat.最後のリベース以降、アップストリームで何が変更されたかのdiffstatを表示します。diffstatは設定オプションrebase.statによっても制御されます。


Do not show a diffstat as part of the rebase process.リベース処理の一環としてdiffstatを表示しないでください。


This option bypasses the pre-rebase hook. See also githooks[5].このオプションはリベース前フックをバイパスします。githooks [5]もご覧ください。

--verify - 確認する

Allows the pre-rebase hook to run, which is the default. This option can be used to override --no-verify. See also githooks[5].リベース前フックの実行を許可します。これはデフォルトです。このオプションは--no-verifyを上書きするために使用できます。githooks [5]もご覧ください。

-C<n> -C <n>

Ensure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist they all must match. By default no context is ever ignored.各変更の前後に、少なくとも<n>行の前後の文脈が一致するようにしてください。周囲の文脈の行が少ない場合、それらはすべて一致しなければなりません。デフォルトでは、コンテキストは無視されません。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。


Individually replay all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the entire history of the rebased branch is composed of new commits.変更されていないコミットを早送りするのではなく、すべてのrebasedコミットを個別に再生します。これにより、リベースされたブランチの全履歴が新しいコミットで構成されるようになります。

You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to "revert the reversion" (see the revert-a-faulty-merge How-To for details).このオプションはトピックブランチを新しいコミットで再作成できるので、「復帰を元に戻す」必要なくトピックブランチを再作成できるので、トピックブランチのマージを取り消した後に役立つことがあります(revert-a- faulty -mergeを参照)。詳細)。

--fork-point - フォークポイント

Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>.どのコミットが<branch>によって導入されたかを計算するときに、<upstream>と<branch>の間のより一般的な祖先を見つけるためにreflogを使用してください。

When --fork-point is active, fork_point will be used instead of <upstream> to calculate the set of commits to rebase, where fork_point is the result of git merge-base --fork-point <upstream> <branch> command (see git-merge-base[1]). If fork_point ends up being empty, the <upstream> will be used as a fallback.--fork-pointが有効な場合、リベースするコミットのセットを計算するために<upstream>の代わりにfork_pointが使用されます。ここで、fork_pointgit merge-base --fork-point <upstream> <branch>command の結果です(git-merge-base [1]を参照)。場合fork_pointが空で終わる、<上流>フォールバックとして使用されます。

If either <upstream> or --root is given on the command line, then the default is --no-fork-point, otherwise the default is --fork-point.コマンドラインで<upstream>または--rootが指定されている場合は--no-fork-point、デフォルトは--fork-pointです。それ以外の場合は、デフォルトはです。

--whitespace=<option> --whitespace = <オプション>

These flag are passed to the git apply program (see git-apply[1]) that applies the patch.これらのフラグは、パッチを適用するgit applyプログラム(git-apply [1]を参照)に渡されます

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。


These flags are passed to git am to easily change the dates of the rebased commits (see git-am[1]).これらのフラグは、リベースされたコミットの日付を簡単に変更するためにgit amに渡されますgit-am [1]を参照)。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

--signoff - サインオフ

Add a Signed-off-by: trailer to all the rebased commits. Note that if --interactive is given then only commits marked to be picked, edited or reworded will have the trailer added.Signed-off-by:トレーラーをすべてのリベースしたコミットに追加します。--interactiveが与えられた場合、選択された、編集された、または書き換えられたとマークされたコミットのみがトレーラーを追加します。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

-i -私
--interactive - インタラクティブ

Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).リベースしようとしているコミットのリストを作成します。ユーザーがリベースする前にそのリストを編集できるようにします。このモードはコミットを分割するためにも使用できます(下記の「コミットの分割」を参照)。

The commit list format can be changed by setting the configuration option rebase.instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.コミットリストのフォーマットは設定オプションrebase.instructionFormatを設定することで変更できます。カスタマイズされた命令フォーマットは自動的にロングコミットハッシュをフォーマットの先頭に追加します。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

--rebase-merges[=(rebase-cousins|no-rebase-cousins)] --rebase-merges [=(rebase-cousins | no-rebase-cousins)]

By default, a rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch. With --rebase-merges, the rebase will instead try to preserve the branching structure within the commits that are to be rebased, by recreating the merge commits. Any resolved merge conflicts or manual amendments in these merge commits will have to be resolved/re-applied manually.デフォルトでは、リベースはToDoリストからマージコミットを削除し、リベースされたコミットを単一の線形ブランチに入れます。では--rebase-merges、代わりに、マージコミットを再作成することによって、リベースはリベースされるコミット内の分岐構造を維持しようとします。これらのマージコミットで解決されたマージ競合または手動の修正は、手動で解決/再適用する必要があります。

By default, or when no-rebase-cousins was specified, commits which do not have <upstream> as direct ancestor will keep their original branch point, i.e. commits that would be excluded by git1's --ancestry-path option will keep their original ancestry by default. If the rebase-cousins mode is turned on, such commits are instead rebased onto <upstream> (or <onto>, if specified).デフォルトで、またはno-rebase-cousins指定されたときには、<upstream>直接の祖先を持たないコミットは元の分岐点を保持します。つまり、git 1--ancestry-pathオプションで除外されるコミットはデフォルトで元の祖先を保持します。rebase-cousinsモードがオンになっている場合、そのようなコミットは代わりに<upstream>(または<onto>指定されている場合は)再配置されます。

The --rebase-merges mode is similar in spirit to --preserve-merges, but in contrast to that option works well in interactive rebases: commits can be reordered, inserted and dropped at will.この--rebase-mergesモードは、精神的には似--preserve-mergesていますが、そのオプションとは対照的に、対話的なリベースでうまく機能します。コミットは、並べ替え、挿入、削除することができます。

It is currently only possible to recreate the merge commits using the recursive merge strategy; Different merge strategies can be used only via explicit exec git merge -s <strategy> [...] commands.現在、recursiveマージ戦略を使用してマージコミットを再作成することのみが可能です。明示的なexec git merge -s <strategy> [...]コマンドを介してのみ異なるマージ戦略を使用できます。

See also REBASING MERGES and INCOMPATIBLE OPTIONS below.下記の「マージのマージ」と「互換性のないオプション」も参照してください。

--preserve-merges --preserve-merge

Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved.マージコミットで発生したコミットを再生して履歴を平坦化するのではなく、マージコミットを再作成します。マージコンフリクトの解決またはマージコミットの手動修正は保持されません。

This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).これは--interactive内部的には機構を使用し--interactiveますが、明示的にオプションと組み合わせることは、自分がしていることが分からない限り、一般的にはお勧めできません(下記のバグを参照)。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

-x <cmd>
--exec <cmd>

Append "exec <cmd>" after each line creating a commit in the final history. <cmd> will be interpreted as one or more shell commands. Any command that fails will interrupt the rebase, with exit code 1.各行の最後に "exec <cmd>"を追加して最終履歴にコミットを作成します。<cmd>は1つ以上のシェルコマンドとして解釈されます。失敗したコマンドはすべて、リベースを中断します。終了コードは1です。

You may execute several commands by either using one instance of --exec with several commands:1つのインスタンス--execを複数のコマンドと共に使用することで、複数のコマンドを実行できます。

git rebase -i --exec "cmd1 && cmd2 && ..."

or by giving more than one --exec:または複数のものを与えることによって--exec

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

If --autosquash is used, "exec" lines will not be appended for the intermediate commits, and will only appear at the end of each squash/fixup series.--autosquashが使用されている場合、 "exec"行は中間コミットには追加されず、各スカッシュ/フィックスアップシリーズの最後にのみ表示されます。

This uses the --interactive machinery internally, but it can be run without an explicit --interactive.これは--interactive内部で機構を使用しますが、明示的に指定しなくても実行できます--interactive

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

--root - ルート

Rebase all commits reachable from <branch>, instead of limiting them with an <upstream>. This allows you to rebase the root commit(s) on a branch. When used with --onto, it will skip changes already contained in <newbase> (instead of <upstream>) whereas without --onto it will operate on every change. When used together with both --onto and --preserve-merges, all root commits will be rewritten to have <newbase> as parent instead.<upstream>で制限するのではなく、<branch>から到達可能なすべてのコミットを元に戻します。これにより、ブランチ上のルートコミットをリベースすることができます。--ontoと共に使用すると、(<upstream>の代わりに)<newbase>に既に含まれている変更をスキップしますが、--ontoを指定しないと、すべての変更に対して機能します。--ontoと--preserve-mergesの両方と一緒に使用すると、すべての rootコミットは代わりに<newbase>を親として持つように書き直されます。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

--autosquash - オートスカッシュ

When the commit log message begins with "squash! …​" (or "fixup! …​"), and there is already a commit in the todo list that matches the same ..., automatically modify the todo list of rebase -i so that the commit marked for squashing comes right after the commit to be modified, and change the action of the moved commit from pick to squash (or fixup). A commit matches the ... if the commit subject matches, or if the ... refers to the commit’s hash. As a fall-back, partial matches of the commit subject work, too. The recommended way to create fixup/squash commits is by using the --fixup/--squash options of git-commit[1].コミットログメッセージが "squash!…"(または "fixup!…")で始まっていて、それと一致するTODOリストにすでにコミットがある場合は...、rebase -iのTODOリストを自動的に変更します。スカッシュ用にマークされたコミットは、変更するコミットの直後に表示され、移動したコミットのアクションをpickからsquash(またはfixup)に変更します。...コミットサブジェクトが一致する場合、または...がコミットのハッシュを参照する場合、コミットは一致します。代替として、コミットサブジェクトの部分一致も機能します。fixup / squashコミットを作成するための推奨される方法はgit-commitの--fixup / --squashoptionsを使うことです[1]

If the --autosquash option is enabled by default using the configuration variable rebase.autoSquash, this option can be used to override and disable this setting.場合は--autosquashオプションが設定変数を使用して、デフォルトで有効になってrebase.autoSquash、このオプションは、この設定を上書きして無効にするために使用することができます。

See also INCOMPATIBLE OPTIONS below.下記の「互換性のないオプション」も参照してください。

--autostash - オートスタッシュ

Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.操作が始まる前に一時的な隠し場所項目を自動的に作成し、操作が終了した後にそれを適用します。これは、汚れた作業ツリーでrebaseを実行できることを意味します。ただし、慎重に使用してください。リベースが成功した後の最後のstashアプリケーションは、重要な衝突を引き起こす可能性があります。


Automatically reschedule exec commands that failed. This only makes sense in interactive mode (or when an --exec option was provided).exec失敗したコマンドを自動的に再スケジュールします。これは対話モード(または--execオプションが提供されたとき)でのみ意味があります。


The following options:以下のオプションがあります。

  • --committer-date-is-author-date

  • --ignore-date

  • --whitespace- 空白

  • --ignore-whitespace

  • -C

are incompatible with the following options:以下のオプションと互換性がありません。

  • --merge- マージ

  • --strategy- 戦略

  • --strategy-option

  • --allow-empty-message

  • --[no-]autosquash- [no-]オートスカッシュ

  • --rebase-merges

  • --preserve-merges--preserve-merge

  • --interactive- インタラクティブ

  • --exec

  • --keep-empty

  • --edit-todo

  • --root when used in combination with --onto--ontoと組み合わせて使用??する場合は--root

In addition, the following pairs of options are incompatible:さらに、次のオプションの組み合わせは互換性がありません。

  • --preserve-merges and --interactive--preserve-mergeおよび--interactive

  • --preserve-merges and --signoff--preserve-mergesと--signoff

  • --preserve-merges and --rebase-merges--preserve-mergesと--rebase-merges

  • --rebase-merges and --strategy--rebase-mergesと--strategy

  • --rebase-merges and --strategy-option--rebase-mergesと--strategy-option


There are some subtle differences how the backends behave.バックエンドの振る舞いは微妙に異なります。

Empty commits空のコミット

The am backend drops any "empty" commits, regardless of whether the commit started empty (had no changes relative to its parent to start with) or ended empty (all changes were already applied upstream in other commits).amバックエンドは、コミットが空で開始された(最初に親に対する変更がなかった)か空で終了した(他のコミットの上流で既にすべての変更が適用されていた)かに関係なく、「空の」コミットをドロップします。

The interactive backend drops commits by default that started empty and halts if it hits a commit that ended up empty. The --keep-empty option exists for the interactive backend to allow it to keep commits that started empty.対話型バックエンドは、デフォルトで空になったコミットを落とし、空になったコミットにヒットすると停止します。--keep-empty対話型バックエンドには、開始されたコミットを空のままにできるようにするためのオプションがあります。

Directory rename detectionディレクトリ名変更検出

Directory rename heuristics are enabled in the merge and interactive backends. Due to the lack of accurate tree information, directory rename detection is disabled in the am backend.ディレクトリリネームヒューリスティックはマージと対話型バックエンドで有効になります。正確なツリー情報がないため、amバックエンドではディレクトリ名の変更検出は無効になっています。


The merge mechanism (git merge and git pull commands) allows the backend merge strategies to be chosen with -s option. Some strategies can also take their own options, which can be passed by giving -X<option> arguments to git merge and/or git pull.マージメカニズム(git mergeおよびgit pullコマンド)を使用すると、オプションでバックエンドのマージ戦略を選択-sできます。いくつかの戦略は独自のオプションを取ることもできます。そしてそれは/ やに-X<option>引数を与えることで渡すことができます。git mergegit pull

resolve 解決する

This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities and is considered generally safe and fast.これは3方向マージアルゴリズムを使用して2つのヘッド(つまり現在のブランチとあなたが引っ張った別のブランチ)を解決することしかできません。危機的なクロスマージのあいまいさを慎重に検出しようとしますが、一般的に安全かつ高速と見なされます。

recursive 再帰的

This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames, but currently cannot make use of detected copies. This is the default merge strategy when pulling or merging one branch.これは3方向マージアルゴリズムを使用して2つのヘッドを解決することしかできません。3者間マージに使用できる共通の祖先が複数ある場合は、共通の祖先のマージされたツリーを作成し、それを3者間マージの参照ツリーとして使用します。これは、Linux 2.6カーネル開発の歴史から取られた実際のマージコミットに対して行われたテストによるミスマージを引き起こすことなく、マージコンフリクトが少なくなると報告されています。さらに、これは名前の変更を含むマージを検出して処理できますが、現在のところ検出されたコピーを利用することはできません。これは、1つのブランチをプルまたはマージするときのデフォルトのマージ戦略です。

The recursive strategy can take the following options:再帰的な戦略は、次のオプションを取ることができます。

ours 私たちのもの

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the merge result. For a binary file, the entire contents are taken from our side.このオプションは私たちのバージョンを支持することによって衝突しているハンクをきれいに自動解決することを強制します。私たちの側と矛盾しない他のツリーからの変更はマージ結果に反映されます。バイナリファイルの場合、内容全体が私たちの側から取られます。

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.これは、他のツリーに含まれているものをまったく見ないという、当社のマージ戦略と混同しないでください。それは他の木がしたすべてを捨てて、私たちの歴史がそれで起こったことすべてを含むと宣言します

theirs 彼らの

This is the opposite of ours; note that, unlike ours, there is no theirs merge strategy to confuse this merge option with.これは私たちの反対です。注意してください、私たちのものとは異なり、このマージオプションを混同する彼らのマージ戦略はありません。

patience 忍耐

With this option, merge-recursive spends a little extra time to avoid mismerges that sometimes occur due to unimportant matching lines (e.g., braces from distinct functions). Use this when the branches to be merged have diverged wildly. See also git-diff[1] --patience.このオプションを指定すると、merge-recursiveは、重要でない一致行(たとえば、異なる関数の中括弧)が原因で発生することがあるミスマージを回避するために、少し余分な時間を費やします。マージされるブランチが激しく分岐したときにこれを使用してください。git-diff [1] もご覧ください--patience

diff-algorithm=[patience|minimal|histogram|myers] diff-algorithm = [忍耐|最小|ヒストグラム|マイヤーズ]

Tells merge-recursive to use a different diff algorithm, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also git-diff[1] --diff-algorithm.伝えマージ再帰的(例えば、別個の機能からブレースなどの)重要でないマッチング線による発生mismergesを回避することができ、異なる差分アルゴリズムを、使用します。git-diff [1] もご覧ください--diff-algorithm

ignore-space-change 無視スペース変更
ignore-all-space 全スペースを無視

Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also git-diff[1] -b, -w, --ignore-space-at-eol, and --ignore-cr-at-eol.3方向マージのために、指定されたタイプの空白変更を持つ行を変更されていないものとして扱います。行に対する他の変更と混在する空白の変更は無視されません。参照してください[1]のgit-diffのに -b-w--ignore-space-at-eol、と--ignore-cr-at-eol

  • If their version only introduces whitespace changes to a line, our version is used;それらのバージョンが行に空白の変更を導入するだけなら、私たちのバージョンが使われます。

  • If our version introduces whitespace changes but their version includes a substantial change, their version is used;場合は、私たちのバージョンが空白の変更を導入したが、そのバージョンは実質的な変化が含まれ、そのバージョンが使用されています。

  • Otherwise, the merge proceeds in the usual way.それ以外の場合、マージは通常の方法で進行します。

renormalize くりこむ

This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See "Merging branches with differing checkin/checkout attributes" in gitattributes[5] for details.これは、3者間マージを解決するときに、ファイルの3つのステージすべての仮想チェックアウトおよびチェックインを実行します。このオプションは、異なるクリーンフィルタまたは行末正規化ルールを使用してブランチをマージするときに使用することを目的としています。詳細はgitattributes [5]の "異なるチェックイン/チェックアウト属性を持つブランチのマージ"を参照してください。

no-renormalize 繰り込まない

Disables the renormalize option. This overrides the merge.renormalize configuration variable.renormalizeオプションを無効にします。これはmerge.renormalize設定変数を上書きします。

no-renames 名前変更なし

Turn off rename detection. This overrides the merge.renames configuration variable. See also git-diff[1] --no-renames.名前変更検出をオフにします。これはmerge.renames設定変数を上書きします。git-diff [1] もご覧ください--no-renames

find-renames[=<n>] 検索リネーム[= <n>]

Turn on rename detection, optionally setting the similarity threshold. This is the default. This overrides the merge.renames configuration variable. See also git-diff[1] --find-renames.名前の変更の検出をオンにし、オプションで類似度のしきい値を設定します。これがデフォルトです。これはmerge.renames設定変数を上書きします。git-diff [1] もご覧ください--find-renames

rename-threshold=<n> 名前変更しきい値= <n>

Deprecated synonym for find-renames=<n>.の廃止予定の同義語find-renames=<n>

subtree[=<path>] サブツリー[= <パス>]

This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.このオプションは、より高度な形式のサブツリー戦略で、2つのツリーをマージ時に一致させるために2つのツリーをどのようにシフトする必要があるかを推測します。代わりに、指定されたパスに接頭語(または先頭から削除)を付けて、2本の木の形状を一致させます。

octopus たこ

This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.これは3つ以上の頭を持つケースを解決しますが、手動の解決を必要とする複雑なマージをすることを拒否します。これは主にトピックブランチのヘッドをまとめるために使われることを意図しています。これは、複数のブランチをプルまたはマージするときのデフォルトのマージ戦略です。

ours 私たちのもの

This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the recursive merge strategy.これは任意の数のヘッドを解決しますが、結果として得られるマージのツリーは常に現在のブランチヘッドのツリーになり、他のすべてのブランチからのすべての変更を事実上無視します。それはサイドブランチの古い開発履歴に取って代わるために使われることを意図しています。これは再帰的マージ戦略の-Xoursオプションとは異なることに注意してください。

subtree サブツリー

This is a modified recursive strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.これは修正された再帰的戦略です。ツリーAとBをマージするとき、BがAのサブツリーに対応する場合、Bは、同じレベルでツリーを読み取るのではなく、まずAのツリー構造と一致するように調整されます。この調整は共通の先祖ツリーに対しても行われます。

With the strategies that use 3-way merge (including the default, recursive), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.3方向マージ(デフォルト、再帰を含む)を使用する戦略では、両方のブランチで変更が行われたが、後で一方のブランチで元に戻された場合、その変更はマージ結果に反映されます。何人かの人々はこの行動が紛らわしいと思います。これは、個々のコミットではなく、マージを実行するときにヘッドとマージベースのみが考慮されるために発生します。したがって、マージアルゴリズムは、元に戻された変更をまったく変更なしと見なし、代わりに変更されたバージョンを代わりに使用します。


You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.あなたが共有するリポジトリでgit rebaseを使うことの意味を理解するべきです。下記の「UPSTREAM REBASEからのリカバリ」も参照してください。

When the git-rebase command is run, it will first execute a "pre-rebase" hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn’t appropriate. Please see the template pre-rebase hook script for an example.git-rebaseコマンドが実行されると、最初に "pre-rebase"フックがあればそれを実行します。このフックを使用して健全性チェックを行い、適切でない場合はリベースを拒否することができます。例としてtemplate pre-rebase hookスクリプトを見てください。

Upon completion, <branch> will be the current branch.完了すると、<branch>が現在の分岐になります。


Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).対話的にリベースするということは、リベースされたコミットを編集する機会があるということです。コミットの順序を変更したり、コミットを削除したりすることができます(悪いパッチやその他の望ましくないパッチを排除)。

The interactive mode is meant for this type of workflow:インタラクティブモードは、このタイプのワークフローを対象としています。

  1. have a wonderful idea素晴らしいアイデアを

  2. hack on the codeコードをハックする

  3. prepare a series for submission提出用のシリーズを準備する

  4. submit提出する

where point 2. consists of several instances ofここで、ポイント2は、

a) regular usea)通常の使用

  1. finish something worthy of a commitコミットに値するものを完成させる

  2. commitコミット

b) independent fixupb)独立修正

  1. realize that something does not work何かがうまくいかないことに気づく

  2. fix thatそれを修正

  3. commit itそれをコミットする

Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of "a"s and "b"s, by rearranging and editing commits, and squashing multiple commits into one.時々b.2で直ったこと。そのコミットはパッチシリーズの中に深く埋め込まれているので、それが修正する完全ではないコミットを修正することはできません。それがまさに対話型リベースの目的です。たくさんの "a"と "b"の後に、コミットを並べ替えて編集し、複数のコミットを1つにまとめることによってそれを使います。

Start it with the last commit you want to retain as-is:そのままにしておきたい最後のコミットから始めましょう。

git rebase -i <after-this-commit>

An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart’s content, and you can remove them. The list looks more or less like this:与えられたコミットの後に来る(マージコミットを無視して)あなたの現在のブランチのすべてのコミットでエディタが起動されます。このリストのコミットをあなたの心の内容に並べ替えることができ、それらを削除することができます。リストは多かれ少なかれこのように見えます:

pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit

The oneline descriptions are purely for your pleasure; git rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.オンラインの説明は純粋にあなたの喜びのためのものです。git rebaseはそれらを見るのではなくコミット名(この例では "deadbee"と "fa1afe1")を見るので、名前を削除したり編集したりしないでください。

By replacing the command "pick" with the command "edit", you can tell git rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.コマンド "pick"をコマンド "edit"に置き換えることで、そのコミットを適用した後にgit rebaseに停止を指示することができ、ファイルやコミットメッセージを編集したり、コミットを修正したり、リベースを続けることができます。

To interrupt the rebase (just like an "edit" command would do, but without cherry-picking any commit first), use the "break" command.リベースを中断するには( "edit"コマンドが実行するのと同じですが、最初にコミットを選択しないで)、 "break"コマンドを使用します。

If you just want to edit the commit message for a commit, replace the command "pick" with the command "reword".コミットメッセージを編集してコミットするだけの場合は、コマンド "pick"をコマンド "reword"に置き換えます。

To drop a commit, replace the command "pick" with "drop", or just delete the matching line.コミットをやめるには、コマンド "pick"を "drop"に置き換えるか、単に一致する行を削除します。

If you want to fold two or more commits into one, replace the command "pick" for the second and subsequent commits with "squash" or "fixup". If the commits had different authors, the folded commit will be attributed to the author of the first commit. The suggested commit message for the folded commit is the concatenation of the commit messages of the first commit and of those with the "squash" command, but omits the commit messages of commits with the "fixup" command.2つ以上のコミットを1つにまとめる場合は、2回目以降のコミットのコマンド「pick」を「squash」または「fixup」に置き換えます。コミットの作者が異なる場合、折り畳まれたコミットは最初のコミットの作者に起因します。折り畳まれたコミットに対して推奨されるコミットメッセージは、最初のコミットのコミットメッセージと "squash"コマンドを持つコミットメッセージの連結ですが、 "fixup"コマンドを持つコミットのコミットメッセージは省略します。

git rebase will stop when "pick" has been replaced with "edit" or when a command fails due to merge errors. When you are done editing and/or resolving conflicts you can continue with git rebase --continue."pick"が "edit"に置き換えられたとき、またはマージエラーが原因でコマンドが失敗したとき、git rebaseは停止します。あなたが編集や衝突の解決を終えたら、続行することができますgit rebase --continue

For example, if you want to reorder the last 5 commits, such that what was HEAD~4 becomes the new HEAD. To achieve that, you would call git rebase like this:たとえば、最後の5つのコミットを並べ替えたい場合、HEAD〜4だったものが新しいHEADになります。それを実現するには、git rebaseを次のように呼び出します。

$ git rebase -i HEAD~5

And move the first patch to the end of the list.そして最初のパッチをリストの最後に移動します。

You might want to preserve merges, if you have a history like this:このような履歴がある場合は、マージを保持したいと思うかもしれません。


Suppose you want to rebase the side branch starting at "A" to "Q". Make sure that the current HEAD is "B", and call"A"から "Q"までのサイドブランチをリベースしたいとします。現在のHEADが "B"であることを確認して、

$ git rebase -i -p --onto Q O

Reordering and editing commits usually creates untested intermediate steps. You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the "exec" command (shortcut "x"). You may do so by creating a todo list like this one:コミットの順序変更と編集は通常、テストされていない中間ステップを作成します。テストを実行するか、または "exec"コマンド(ショートカット "x")を使用して少なくとも履歴の途中で再コンパイルすることで、履歴の編集で問題が発生しなかったことを確認することをお勧めします。あなたはこれのようなToDoリストを作成することによってそうすることができます:

pick deadbee Implement feature XXX
fixup f1a5c00 Fix to feature XXX
exec make
pick c0ffeee The oneline of the next commit
edit deadbab The oneline of the commit after
exec cd subdir; make test

The interactive rebase will stop when a command fails (i.e. exits with non-0 status) to give you an opportunity to fix the problem. You can continue with git rebase --continue.対話的なリベースは、問題が解決する機会を与えるために、コマンドが失敗すると(つまり、0以外のステータスで終了すると)停止します。あなたは続けることができgit rebase --continueます。

The "exec" command launches the command in a shell (the one specified in $SHELL, or the default shell if $SHELL is not set), so you can use shell features (like "cd", ">", ";" …​). The command is run from the root of the working tree."exec"コマンドはシェル(で指定されたもの$SHELL、または$SHELL設定されていない場合はデフォルトのシェル)でコマンドを起動するので、シェル機能( "cd"、 ">"、 ";"など)を使用できます。コマンドは作業ツリーのルートから実行されます。

$ git rebase -i --exec "make test"

This command lets you check that intermediate commits are compilable. The todo list becomes like that:このコマンドを使用すると、中間コミットがコンパイル可能であることを確認できます。ToDoリストは次のようになります。

pick 5928aea one
exec make test
pick 04d0fda two
exec make test
pick ba46169 three
exec make test
pick f4593f9 four
exec make test

SPLITTING COMMITSスプリッティングコミットメント

In interactive mode, you can mark commits with the action "edit". However, this does not necessarily mean that git rebase expects the result of this edit to be exactly one commit. Indeed, you can undo the commit, or you can add other commits. This can be used to split a commit into two:対話モードでは、あなたはアクション "edit"でコミットをマークすることができます。しかし、これは必ずしもgit rebaseがこの編集の結果が正確に1つのコミットになることを期待しているという意味ではありません。実際には、コミットを元に戻すことも、他のコミットを追加することもできます。これはコミットを2つに分割するために使うことができます。

  • Start an interactive rebase with git rebase -i <commit>^, where <commit> is the commit you want to split. In fact, any commit range will do, as long as it contains that commit.対話的なリベースを開始しますgit rebase -i <commit>^。ここで、<commit>は分割したいコミットです。実際、そのコミットが含まれている限り、どのようなコミット範囲でも可能です。

  • Mark the commit you want to split with the action "edit".分割したいコミットをアクション "edit"でマークします。

  • When it comes to editing that commit, execute git reset HEAD^. The effect is that the HEAD is rewound by one, and the index follows suit. However, the working tree stays the same.そのコミットの編集に関しては、実行してくださいgit reset HEAD^。その結果、HEADが1つ巻き戻され、インデックスがそれに追従します。ただし、作業ツリーは変わりません。

  • Now add the changes to the index that you want to have in the first commit. You can use git add (possibly interactively) or git gui (or both) to do that.それでは、最初のコミットで変更したいインデックスに追加しましょう。それをするためにgit add(おそらく対話的に)またはgit gui(あるいはその両方)を使うことができます。

  • Commit the now-current index with whatever commit message is appropriate now.適切なコミットメッセージを使用して、現在のインデックスをコミットします。

  • Repeat the last two steps until your working tree is clean.作業ツリーがきれいになるまで、最後の2つの手順を繰り返します。

  • Continue the rebase with git rebase --continue.でリベースを続行してくださいgit rebase --continue

If you are not absolutely sure that the intermediate revisions are consistent (they compile, pass the testsuite, etc.) you should use git stash to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary.中間のリビジョンが一貫しているかどうかが絶対にわからない(コンパイル、テストスイートに合格するなど)場合は、git stashを使用して、コミット後にまだコミットされていない変更を隠します。必要です。


Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.他の人がベースにしているブランチをリベースする(あるいは他の形式のリライト)ことは悪い考えです:それより下流の誰もが手作業で彼らの歴史を直すことを強いられます。このセクションでは、ダウンストリームの観点から修正を行う方法について説明します。しかし、本当の解決策はそもそもアップストリームのリベースを避けることです。

To illustrate, suppose you are in a situation where someone develops a subsystem branch, and you are working on a topic that is dependent on this subsystem. You might end up with a history like the following:例えば、あなたが誰かがサブシステムブランチを開発している状況にあり、あなたがこのサブシステムに依存しているトピックに取り組んでいると仮定しましょう。あなたは次のような歴史に終わるかもしれません:

    o---o---o---o---o---o---o---o  master
	  o---o---o---o---o  subsystem
			    *---*---*  topic

If subsystem is rebased against master, the following happens:場合は、サブシステムが反対リベースされたマスター、次の処理が行われます。

    o---o---o---o---o---o---o---o  master
	 \			 \
	  o---o---o---o---o	  o'--o'--o'--o'--o'  subsystem
			    *---*---*  topic

If you now continue development as usual, and eventually merge topic to subsystem, the commits from subsystem will remain duplicated forever:あなたは今、いつものように開発を継続し、最終的に合併した場合のトピックにするサブシステムからのコミットサブシステムは、永遠に複製されたままになります。

    o---o---o---o---o---o---o---o  master
	 \			 \
	  o---o---o---o---o	  o'--o'--o'--o'--o'--M	 subsystem
			   \			     /
			    *---*---*-..........-*--*  topic

Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to transplant the commits on topic to the new subsystem tip, i.e., rebase topic. This becomes a ripple effect: anyone downstream from topic is forced to rebase too, and so on!そのような複製は、歴史を乱雑にして従うのを難しくするので、一般的に眉をひそめます。物事を整理するには、topicのコミットを新しいサブシステムの tip、すなわちトピックのリベースに移植する必要があります。これは波及効果になります。トピックから下流の誰もがリベースを余儀なくされるなどです。

There are two kinds of fixes, discussed in the following subsections:次のサブセクションで説明するように、2種類の修正があります。

Easy case: The changes are literally the same. 簡単な例:変更は文字通り同じです。

This happens if the subsystem rebase was a simple rebase and had no conflicts.これは、サブシステムのリベースが単純なリベースで競合が発生していない場合に発生します。

Hard case: The changes are not the same. ハードケース:変更は同じではありません。

This happens if the subsystem rebase had conflicts, or used --interactive to omit, edit, squash, or fixup commits; or if the upstream used one of commit --amend, reset, or filter-branch.これは、サブシステムのリベースに競合がある場合--interactive、またはコミットの省略、編集、縮小、または修正のために使用された場合に起こります。場合、または上流のいずれかを使用するcommit --amendresetまたはfilter-branch

The easy case簡単なケース

Only works if the changes (patch IDs based on the diff contents) on subsystem are literally the same before and after the rebase subsystem did.サブシステムの変更(差分の内容に基づくパッチID)が、リベースサブシステムの前後で文字通り同じである場合にのみ機能します。

In that case, the fix is easy because git rebase knows to skip changes that are already present in the new upstream. So if you say (assuming you’re on topic)その場合、git rebaseは新しいアップストリームに既に存在する変更をスキップすることを知っているので、修正は簡単です。あなたが言うならば(あなたが話題になっていると仮定して)

    $ git rebase subsystem

you will end up with the fixed historyあなたは決まった歴史に終わるでしょう

    o---o---o---o---o---o---o---o  master
				  o'--o'--o'--o'--o'  subsystem
						    *---*---*  topic

The hard caseハードケース

Things get more complicated if the subsystem changes do not exactly correspond to the ones before the rebase.サブシステムの変更がリベース前の変更に正確に対応していない場合、状況はさらに複雑になります

Note While an "easy case recovery" sometimes appears to be successful even in the hard case, it may have unintended consequences. For example, a commit that was removed via git rebase --interactive will be resurrected! "簡単なケースの回復"は、困難なケースでも成功するように見えることがありますが、意図しない結果を招く可能性があります。例えば、それは介して除去されたコミットgit rebase --interactiveされます復活

The idea is to manually tell git rebase "where the old subsystem ended and your topic began", that is, what the old merge-base between them was. You will have to find a way to name the last commit of the old subsystem, for example:考えは手動でgit rebaseに "古いサブシステムが終了してあなたのトピックが始まった場所"、つまりそれらの間の古いマージベースが何であるかを伝えることです。古いサブシステムの最後のコミットに名前をつける方法を見つける必要があります。例えば:

  • With the subsystem reflog: after git fetch, the old tip of subsystem is at subsystem@{1}. Subsequent fetches will increase the number. (See git-reflog[1].)サブシステム REFLOG:後にgitのフェッチ、古い先端サブシステムがですsubsystem@{1}。その後のフェッチは数を増やします。(git-reflog [1]を見てください。)

  • Relative to the tip of topic: knowing that your topic has three commits, the old tip of subsystem must be topic~3.トピックの先端に関連して:あなたのトピックに3つのコミットがあることを知っているなら、サブシステムの古い先端はなければなりませんtopic~3

You can then transplant the old subsystem..topic to the new tip by saying (for the reflog case, and assuming you are on topic already):subsystem..topic(reflogの場合は、すでに話題になっていると仮定して)次のように言うことで、古いものを新しいものに移植できます。

    $ git rebase --onto subsystem subsystem@{1}

The ripple effect of a "hard case" recovery is especially bad: everyone downstream from topic will now have to perform a "hard case" recovery too!「ハードケース」リカバリの波及効果は特に悪いです。トピックから下流の全員が「ハードケース」リカバリも実行する必要があります。


The interactive rebase command was originally designed to handle individual patch series. As such, it makes sense to exclude merge commits from the todo list, as the developer may have merged the then-current master while working on the branch, only to rebase all the commits onto master eventually (skipping the merge commits).対話的なrebaseコマンドはもともと個々のパッチシリーズを処理するために設計されました。そのため、開発者はmasterブランチの作業中に当時のフローをマージした可能性があるため、すべてのコミットをmaster最終的にリベースする(マージコミットをスキップする)ために、マージコミットをToDoリストから除外することは理にかなっています。

However, there are legitimate reasons why a developer may want to recreate merge commits: to keep the branch structure (or "commit topology") when working on multiple, inter-related branches.しかし、開発者がマージコミットを作り直すことを望む正当な理由があります。それは、相互に関連する複数のブランチで作業するときにブランチ構造(または "コミットトポロジ")を維持するためです。

In the following example, the developer works on a topic branch that refactors the way buttons are defined, and on another topic branch that uses that refactoring to implement a "Report a bug" button. The output of git log --graph --format=%s -5 may look like this:次の例では、開発者はボタンの定義方法をリファクタリングするトピックブランチと、そのリファクタリングを使用して「バグの報告」ボタンを実装する別のトピックブランチを操作します。の出力は次のgit log --graph --format=%s -5ようになります。

*   Merge branch 'report-a-bug'
| * Add the feedback button
* | Merge branch 'refactor-button'
|\ \
| |/
| * Use the Button class for all buttons
| * Extract a generic Button class from the DownloadButton one

The developer might want to rebase those commits to a newer master while keeping the branch topology, for example when the first topic branch is expected to be integrated into master much earlier than the second one, say, to resolve merge conflicts with changes to the DownloadButton class that made it into master.masterたとえば、最初のトピックブランチが2番目のトピックブランチmasterよりもはるかに早く統合されることが予想される場合、開発者はブランチトポロジを維持しながらこれらのコミットを新しいコミットにリベースしたい場合があります。になったmaster

This rebase can be performed using the --rebase-merges option. It will generate a todo list looking like this:このリベースは、--rebase-mergesオプションを使用して実行できます。これは、次のようなToDoリストを生成します。

label onto
# Branch: refactor-button
reset onto
pick 123456 Extract a generic Button class from the DownloadButton one
pick 654321 Use the Button class for all buttons
label refactor-button
# Branch: report-a-bug
reset refactor-button # Use the Button class for all buttons
pick abcdef Add the feedback button
label report-a-bug
reset onto
merge -C a1b2c3 refactor-button # Merge 'refactor-button'
merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'

In contrast to a regular interactive rebase, there are label, reset and merge commands in addition to pick ones.定期的な対話的なリベースとは対照的に、そこにあるlabelresetmergeコマンドに加えてpickのもの。

The label command associates a label with the current HEAD when that command is executed. These labels are created as worktree-local refs (refs/rewritten/<label>) that will be deleted when the rebase finishes. That way, rebase operations in multiple worktrees linked to the same repository do not interfere with one another. If the label command fails, it is rescheduled immediately, with a helpful message how to proceed.このlabelコマンドが実行されると、コマンドは現在のHEADにラベルを関連付けます。これらのラベルはworktree-local refs(refs/rewritten/<label>)として作成され、リベースが終了すると削除されます。このようにして、同じリポジトリにリンクされている複数のワークツリー内のリベース操作が互いに干渉することはありません。labelコマンドが失敗した場合は、すぐに再スケジュールされ、続行方法に関する有用なメッセージが表示されます。

The reset command resets the HEAD, index and worktree to the specified revision. It is similar to an exec git reset --hard <label>, but refuses to overwrite untracked files. If the reset command fails, it is rescheduled immediately, with a helpful message how to edit the todo list (this typically happens when a reset command was inserted into the todo list manually and contains a typo).このresetコマンドは、HEAD、索引、および作業ツリーを指定されたリビジョンにリセットします。それはと似ていexec git reset --hard <label>ますが、追跡されていないファイルを上書きすることを拒否します。resetコマンドが失敗した場合は、ToDoリストの編集方法に関する有用なメッセージとともに、すぐにスケジュールが変更されます(これは通常reset、ToDoリストに手動でコマンドが挿入され、タイプミスが含まれている場合に発生します)。

The merge command will merge the specified revision(s) into whatever is HEAD at that time. With -C <original-commit>, the commit message of the specified merge commit will be used. When the -C is changed to a lower-case -c, the message will be opened in an editor after a successful merge so that the user can edit the message.mergeコマンドは、その時点でHEADが何であれに指定されたリビジョン(複数可)をマージします。では-C <original-commit>、指定されたマージのコミットメッセージが使用されますコミット。が-C小文字に変更される-cと、ユーザーがメッセージを編集できるように、マージが成功した後にメッセージがエディターで開かれます。

If a merge command fails for any reason other than merge conflicts (i.e. when the merge operation did not even start), it is rescheduled immediately.mergeマージの競合以外の何らかの理由でコマンドが失敗した場合(つまり、マージ操作が開始されなかった場合など)は、ただちに再スケジュールされます。

At this time, the merge command will always use the recursive merge strategy for regular merges, and octopus for octopus merges, with no way to choose a different one. To work around this, an exec command can be used to call git merge explicitly, using the fact that the labels are worktree-local refs (the ref refs/rewritten/onto would correspond to the label onto, for example).現時点では、このmergeコマンドは通常のマージ、およびタコのマージには常にrecursiveマージ方法を使用octopusします。別の方法を選択することはできません。これを回避するには、ラベルをワークツリーローカルの参照(たとえば、参照はラベルに対応する)にするという事実をexec使用して、コマンドを使用してgit merge明示的に呼び出すことができます。refs/rewritten/ontoonto

Note: the first command (label onto) labels the revision onto which the commits are rebased; The name onto is just a convention, as a nod to the --onto option.注意:最初のコマンド(label onto)はコミットがリベースされたリビジョンにラベルを付けます。オプションontoへのうなずきとして、名前は単なる慣例--ontoです。

It is also possible to introduce completely new merge commits from scratch by adding a command of the form merge <merge-head>. This form will generate a tentative commit message and always open an editor to let the user edit it. This can be useful e.g. when a topic branch turns out to address more than a single concern and wants to be split into two or even more topic branches. Consider this todo list:フォームのコマンドを追加することによって、まったく新しいマージコミットを最初から導入することもできmerge <merge-head>ます。このフォームは暫定的なコミットメッセージを生成し、ユーザが編集できるように常にエディタを開きます。これは、トピックブランチが複数の問題に対処することが判明し、2つ以上のトピックブランチに分割したい場合などに便利です。このToDoリストを検討してください。

pick 192837 Switch from GNU Makefiles to CMake
pick 5a6c7e Document the switch to CMake
pick 918273 Fix detection of OpenSSL in CMake
pick afbecd http: add support for TLS v1.3
pick fdbaec Fix detection of cURL in CMake on Windows

The one commit in this list that is not related to CMake may very well have been motivated by working on fixing all those bugs introduced by switching to CMake, but it addresses a different concern. To split this branch into two topic branches, the todo list could be edited like this:このリストの中でCMakeに関連しない1つのコミットは、CMakeに切り替えることによってもたらされたそれらすべてのバグの修正に取り組むことによって動機づけられた可能性がありますが、別の懸念に対処しています。このブランチを2つのトピックブランチに分割するには、仕事リストを次のように編集します。

label onto
pick afbecd http: add support for TLS v1.3
label tlsv1.3
reset onto
pick 192837 Switch from GNU Makefiles to CMake
pick 918273 Fix detection of OpenSSL in CMake
pick fdbaec Fix detection of cURL in CMake on Windows
pick 5a6c7e Document the switch to CMake
label cmake
reset onto
merge tlsv1.3
merge cmake


The todo list presented by --preserve-merges --interactive does not represent the topology of the revision graph. Editing commits and rewording their commit messages should work fine, but attempts to reorder commits tend to produce counterintuitive results. Use --rebase-merges in such scenarios instead.によって表示されるToDoリスト--preserve-merges --interactiveは、リビジョングラフのトポロジを表しません。コミットの編集とコミットメッセージの書き換えはうまくいくはずですが、コミットの順序を変えようとすると直感に反する結果になります。--rebase-mergesそのようなシナリオで代わりに使用してください。

For example, an attempt to rearrangeたとえば、並べ替えの試み

1 --- 2 --- 3 --- 4 --- 5


1 --- 2 --- 4 --- 3 --- 5

by moving the "pick 4" line will result in the following history:「pick 4」行を移動すると、次のような履歴になります。

1 --- 2 --- 4 --- 5


Part of the git[1] suite一部のgit [1]スイート