git rebase 作用
git-rebase(认真看，分析很到位)-cengku-ChinaUnix博客
git-rebase用法总结-cengku-ChinaUnix博客
what’s is the different between git rebase and git meger. – 何锦彬 – 博客园
git rebase 解释
merge和rebase详解 — GitHub不完全装B指南 — 传送门
去看看git rebase —help的解释：
GIT-REBASE(1) Git Manual GIT-REBASE(1) NAME git-rebase – Forward-port local commits to the updated upstream head SYNOPSIS 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 | –edit-todo DESCRIPTION If <branch> is specified, git rebase will perform an automatic git checkout <branch> before doing anything else. Otherwise it remains on the current 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. 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. 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. 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). 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. Assume the following history exists and the current branch is "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. 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): 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. 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: 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. 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: 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 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. 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 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 –abort CONFIGURATION rebase.stat Whether to show a diffstat of what changed upstream since the last rebase. False by default. rebase.autoSquash If set to true enable <span style="font: 11.0px Menlo; font-variant-ligatures: no-common-ligatures; text-decoration: underline;"–<autosquash option by default. rebase.autoStash If set to true enable <span style="font-size: 11px; font-family: Menlo; text-decoration: underline;"–<autostash option by default. OPTIONS –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. 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. <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. –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. –keep-empty Keep the commits that do not change anything from its parents in the result. –skip Restart the rebasing process by skipping the current patch. –edit-todo Edit the todo list during an interactive rebase. -m, –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. 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. -s <strategy>, –strategy=<strategy> Use the given merge strategy. If there is no -s option git merge-recursive is used instead. This implies –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 discards all patches from the <branch>, which makes little sense. -X <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. -S[<keyid>], –gpg-sign[=<keyid>] GPG-sign commits. -q, –quiet Be quiet. Implies –no-stat. -v, –verbose Be verbose. Implies –stat. –stat Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase.stat. -n, –no-stat Do not show a diffstat as part of the rebase process. –no-verify This option bypasses the pre-rebase hook. See also 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). -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. -f, –force-rebase Force a rebase even if the current branch is up-to-date and the command without –force would return without doing anything. You may find this (or –no-ff with an interactive rebase) 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[1] for details). –fork-point, –no-fork-point Use reflog to find a better common ancestor between <upstream> and <branch> when calculating which commits have been introduced by <branch>. 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. If either <upstream> or –root is given on the command line, then the default is –no-fork-point, otherwise the default is –fork-point. –ignore-whitespace, –whitespace=<option> These flag are passed to the git apply program (see git-apply(1)) that applies the patch. Incompatible with the –interactive option. –committer-date-is-author-date, –ignore-date These flags are passed to git am to easily change the dates of the rebased commits (see git- am(1)). Incompatible with the –interactive option. -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). -p, –preserve-merges 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). -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. This option can only be used with the –interactive option (see INTERACTIVE MODE below). You may execute several commands by either using one instance of –exec with several commands: git rebase -i –exec "cmd1 && cmd2 && …" or by giving more than one –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. –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. –autosquash, –no-autosquash When the commit log message begins with "squash! …" (or "fixup! …"), and there is a commit whose title begins with 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). Ignores subsequent "fixup! " or "squash! " after the first, in case you referred to an earlier fixup/squash with git commit –fixup/–squash. This option is only valid when the <span style="font: 11.0px Menlo; font-variant-ligatures: no-common-ligatures; text-decoration: underline;"–<interactive option is used. If the <span style="font: 11.0px Menlo; font-variant-ligatures: no-common-ligatures; text-decoration: underline;"–<autosquash option is enabled by default using the configuration variable rebase.autoSquash, this option can be used to override and disable this setting. –[no-]autostash Automatically create a temporary stash 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. –no-ff With –interactive, cherry-pick 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. Without –interactive, this is a synonym for –force-rebase. 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[1] for details). MERGE STRATEGIES 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. 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. 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. This is the default merge strategy when pulling or merging one branch. 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. 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. diff-algorithm=[patience|minimal|histogram|myers] Tells merge-recursive to use a different diff algorithm, which can help avoid mismerges that 。。。。。。 |
使用git Rebase让历史变得清晰 – Ji ZHANG’s Blog
【总结】
5.1 代码合并：Merge、Rebase的选择 · geeeeeeeeek/git-recipes Wiki · GitHub
解释的相对最清楚。
其最终目的是：
把新的分支，在想要合并到主分支之前
但是由于主分支已经有更新了
用rebase实现：
把主分支的几个更新，弄到新分支上来，重新再去合并
-》使得主分支上面，就不会出现很多的分支和并入了。
抽空还是要继续学习Git，
可以先看看：
解释的比较易懂。
转载请注明：在路上 » 【整理】git的rebase的作用和用法