最新消息:20190717 VPS服务器:Vultr新加坡,WordPress主题:大前端D8,统一介绍入口:关于

【整理】git的rebase的作用和用法

Git crifan 1031浏览 0评论

git rebase 作用

git rebase小计(转) – 飞林沙 – 博客园

git-rebase(认真看,分析很到位)-cengku-ChinaUnix博客

git-rebase用法总结-cengku-ChinaUnix博客

Git Book 中文版 – rebase

what’s is the different between git rebase and git meger. – 何锦彬 – 博客园

git rebase 解释

Git远程操作详解 – 阮一峰的网络日志

git merge与git rebase的区别

图解Git

Git – 分支的衍合

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

【总结】

Git Rebase

5.1 代码合并:Merge、Rebase的选择 · geeeeeeeeek/git-recipes Wiki · GitHub

解释的相对最清楚。

其最终目的是:

把新的分支,在想要合并到主分支之前

但是由于主分支已经有更新了

用rebase实现:

把主分支的几个更新,弄到新分支上来,重新再去合并

-》使得主分支上面,就不会出现很多的分支和并入了。

抽空还是要继续学习Git,

可以先看看:

Git远程操作详解 – 阮一峰的网络日志

解释的比较易懂。

转载请注明:在路上 » 【整理】git的rebase的作用和用法

发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
57 queries in 0.252 seconds, using 18.90MB memory