Page History

...

$ git log m/[codeline]..

Synopsis

$ git log [<options>] [<revision range>] [[--] <path>…​]

Options

• --follow         :Continue listing the history of a file beyond renames (works only for a single file).
• --source         :Print out the ref name given on the command line by which each commit was reached.
• --log-size        :Include a line “log size <number>” in the output for each commit, where <number> is the length of that commit’s message in bytes. 
• -L <start>,<end>:< file>  , -L  :<funcname>:<file> : Trace the evolution of the line range given by "<start>,<end>" (or the function name regex <funcname>) within the <file>.
• -<number>n <number>-max-count=<number>    : Limit the number of commits to output.
• --skip=<number> : Skip number commits before starting to show the commit output.

Example

$ git log --no-merges

Show the whole commit history, but skip any merges

...

• -i , --interactive : Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing.
• --continue          : Restart the rebasing process after having resolved a merge conflict.
• --abort               :Abort the rebase operation and reset HEAD to the original branch.
• --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.
• --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.
• --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.
• --show-current-patch  :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.

Example

$ git rebase --interactive

To squash a series of commits into a single commit.

...

• list [<options>]                      : List the stash entries that you currently have. Eachstash entryis listed with its name (e.g.stash@{0}is the latest entry,stash@{1}is the one before, etc.),
• show [<options>] [<stash>] :  Show the changes recorded in the stash entry as a diff between the stashed contents and the commit back when the stash entry was first created.
• drop [-q|--quiet] [<stash>]  :  Remove a single stash entry from the list of stash entries. When no<stash>is given, it removes the latest one. i.e.stash@{0}, otherwise<stash>must be a valid stash log reference of the formstash@{<revision>}.
• branch <branchname> [<stash>] : Creates and checks out a new branch named<branchname>starting from the commit at which the<stash>was originally created, applies the changes recorded in<stash>to the new working tree and index. If that succeeds, and<stash>is a reference of the formstash@{<revision>}, it then drops the<stash>. When no<stash>is given, applies the latest one.
• clear    : Removes all the stash entries
• create : Create a stash entry (which is a regular commit object) and return its object name, without storing it anywhere in the ref namespace.
• store  :Store a given stash created via git stash create (which is a dangling merge commit) in the stash ref, updating the stash reflog. 

Example

$ git pull
 ...
file foobar not up to date, cannot merge.
$ git stash
$ git pull
$ git stash pop

there are cases in which your local changes do conflict with the upstream changes, and git pull refuses to overwrite your changes. In such a case, you can stash your changes away, perform a pull, and then unstash, like above.

...