1. You can do absolutely anything on your local branch and revert back by running git reset --hard [REV] and it will go back, losing all changes (read more on git reset here) You can find the hash revision to use by git reflog - all changes (even checkouts) are listed there with the previous revision shown, so you can easily undo even the most complex changes. You can find previous regular commits using git log and reset to them in the same way.

2. If you have a merge that "took too many commits with it", this should be solved by rebasing the branch before merging. Often this is requested of the submitter before merging. I imagine the problem was that a branch was created off the 1.4.5 branch, but pull request created against master.

• You can see this easily ahead of time by looking at the commit log on the pull request, and simply request in a comment that it be rebased before being merged in.
• Or if you want to do it yourself, just checkout the feature branch, then run git rebase -i master and only select the commits relevant to the feature. This is complicated to do but very powerful - read up on interactive rebase for more.

3. If you end up in a merge with conflicts, you should resolve them manually.

• git status will show you which files have conflicts. Resolve them using a diff/merge program or just a text editor.
• Once resolved, git add [conflictedfiles] (since you still have not committed the merge) and then you may git commit -v to commit the merge with resolved conflicts.
• If you want to go back and try something different at that point, you may run git merge --abort or git rebase --abort depending on what you initially ran.

4. Rebases of master or another mainline branch should not generally be necessary unless you're trying to merge into a local branch that no one else has checked out, or merge in a special way. A rebase will almost always rewrite history and cause problems with branches used for collaboration, such as master or development (see #.5 below). You should almost never rebase master from another branch. Whenever you are thinking to rebase, you probably mean to do a simple git merge branch_name and it will work much better.

5. If you ever do "rewrite history" on a main branch and push it, (intentionally or unintentionally) you don't ever need to destroy the branch—just git push -f to force push the branch in whatever state you want it to be, and then people will simply have to force pull it to overwrite their local branches (with git pull -f). Not the end of the world, and easier than re-creating the branch from nothing.

6. You can easily revert (reverse) a single commit by committing another revert commit to reverse the commit or range of commits you want to undo. This is cleaner if the change was intended and made it to the main branch, but needs to be reversed, so that all history is kept. Run git revert COMMIT..RANGE, for example git revert HEAD^3 to revert the 3rd-to-last commit, or git revert 81af24c..104c7be to revert all commits between and including those two.

git fetch to bring down all new branches and sync with the remote without merging anything.

First create your new temporary branch, starting with whatever branch you want it based on -- git checkout master then git checkout -b branchname

(As an interim step here, you may have to add the user's fork as a separate remote. To do this, run git remote add <userxyz> https://github.com/<userxyz>/<repository>.git—then git fetch <userxyz> again to pull down their branch, and replace origin below with <userxyz>, the name you gave to their fork. Their <pull_request_branch_name> is most likely master.) Review your remotes by git remote.

Next merge the remote branch that the pull is for: git merge origin/<pull_request_branch_name>

The steps would be similar with a GUI client—create and checkout the new branch, then merge with the remote pull request branch.

Alternatively, you can simply check out their fork to test. Add the remote for the user's fork as in the instruction in parentheses above, then simply check it out: git checkout userxyz/branch_name. You can test right there with their code, or create a new branch based on it to continue testing, whatever you like.