Useful Git Commands

git_stuff.md

Uses the git rev-parse command with a ref to HEAD to return the hash of the current commit.

git rev-parse HEAD

or

git rev-parse @

View log of the last 2 commits that will be rebased:

git log --pretty=format:"%h %s" HEAD~1..HEAD

Start rebase:

git rebase -i HEAD~1

Basically have to specify for each commit in the range what to do.

See here for instructions.

You can avoid using the --onto parameter by making a temp branch on the commit you like and then use rebase in it's simple form:

git branch temp master^
git checkout topic
git rebase temp
git branch -d temp

http://stackoverflow.com/questions/7744049/git-how-to-rebase-to-a-specific-commit

git rebase would be one way to do this, but I think I would recommend git cherry-pick instead:

git checkout develop
git cherry-pick c..h

The main difference is that git cherry-pick won't move your my-bug-fix and my-bug-fix-develop refs - it will just advance develop with the new commits that are copies of the change sets made in commits d through h.

If you would prefer to have the side branch and merge commit on develop, though, so that it looks somewhat like the original branch, then do this instead:

git checkout -b develop-bug-fix develop
git cherry-pick c..h
git checkout develop
git merge --no-ff develop-bug-fix

http://stackoverflow.com/questions/23961137/rebasing-to-move-over-a-set-of-commits-from-one-branch-to-another-is-my-underst

The way a cherry-pick works is by taking the diff a changeset represents (the difference between the working tree at that point and the working tree of its parent), and applying it to your current branch.

So, if a commit has two or more parents, it also represents two or more diffs - which one should be applied?

You're trying to cherry pick fd9f578, which was a merge with two parents. So you need to tell the cherry-pick command which one against which the diff should be calculated, by using the -m option. For example, git cherry-pick -m 1 fd9f578 to use parent 1 as the base.

I can't say for sure for your particular situation, but using git merge instead of git cherry-pick is generally advisable. When you cherry-pick a merge commit, it collapses all the changes made in the parent you didn't specify to -m into that one commit. You lose all their history, and glom together all their diffs. Your call.

http://stackoverflow.com/questions/9229301/git-cherry-pick-says-38c74d-is-a-merge-but-no-m-option-was-given

320
down vote
accepted
Git 1.7.2 introduced the ability to cherrypick a range of commits. From the release notes:

git cherry-pick" learned to pick a range of commits (e.g. "cherry-pick A..B" and "cherry-pick --stdin"), so did "git revert"; these do not support the nicer sequencing control "rebase [-i]" has, though.
Including important comments (credits to respective authors)

Note 1: In the "cherry-pick A..B" form, A should be older than B. If they're the wrong order the command will silently fail. – damian

Note 2: Also, this will not cherry-pick A, but rather everything after A up to and including B. – J. B. Rainsberger

Note 3: To include A just type git cherry-pick A^..B – sschaef

http://stackoverflow.com/questions/1670970/how-to-cherry-pick-multiple-commits