Git – I can`t Push the branch to , along with necessary commits and objects

NOTE: This answer changes SHA1s, so take care when using it on a branch that has already been pushed. If you only want to fix the spelling of a name or update an old email, git lets you do this without rewriting history using .mailmap. See my other answer.

Using Interactive Rebase

You could do

git rebase -i -p <some HEAD before all of your bad commits>

Then mark all of your bad commits as "edit" in the rebase file. If you also want to change your first commit, you have to manually add it as the first line in the rebase file (follow the format of the other lines). Then, when git asks you to amend each commit, do

 git commit --amend --author "New Author Name <email@address.com>" 

edit or just close the editor that opens, and then do

git rebase --continue

to continue the rebase.

You could skip opening the editor altogether here by appending --no-edit so that the command will be:

git commit --amend --author "New Author Name <email@address.com>" --no-edit && \
git rebase --continue

Single Commit

As some of the commenters have noted, if you just want to change the most recent commit, the rebase command is not necessary. Just do

 git commit --amend --author "New Author Name <email@address.com>"

This will change the author to the name specified, but the committer will be set to your configured user in git config user.name and git config user.email. If you want to set the committer to something you specify, this will set both the author and the committer:

 git -c user.name="New Author Name" -c user.email=email@address.com commit --amend --reset-author

Note on Merge Commits

There was a slight flaw in my original response. If there are any merge commits between the current HEAD and your <some HEAD before all your bad commits>, then git rebase will flatten them (and by the way, if you use GitHub pull requests, there are going to be a ton of merge commits in your history). This can very often lead to a very different history (as duplicate changes may be "rebased out"), and in the worst case, it can lead to git rebase asking you to resolve difficult merge conflicts (which were likely already resolved in the merge commits). The solution is to use the -p flag to git rebase, which will preserve the merge structure of your history. The manpage for git rebase warns that using -p and -i can lead to issues, but in the BUGS section it says "Editing commits and rewording their commit messages should work fine."

I've added -p to the above command. For the case where you're just changing the most recent commit, this is not an issue.

Update for modern git clients (July 2020)

Use --rebase-merges instead of -p (-p is deprecated and has serious issues).

Moving to an existing branch

If you want to move your commits to an existing branch, it will look like this:

git checkout existingbranch
git merge master
git checkout master
git reset --hard HEAD~3 # Go back 3 commits. You *will* lose uncommitted work.
git checkout existingbranch

You can store uncommitted edits to your stash before doing this, using git stash. Once complete, you can retrieve the stashed uncommitted edits with git stash pop

Moving to a new branch

WARNING: This method works because you are creating a new branch with the first command: git branch newbranch. If you want to move commits to an existing branch you need to merge your changes into the existing branch before executing git reset --hard HEAD~3 (see Moving to an existing branch above). If you don't merge your changes first, they will be lost.

Unless there are other circumstances involved, this can be easily done by branching and rolling back.

# Note: Any changes not committed will be lost.
git branch newbranch      # Create a new branch, saving the desired commits
git reset --hard HEAD~3   # Move master back by 3 commits (Make sure you know how many commits you need to go back)
git checkout newbranch    # Go to the new branch that still has the desired commits

But do make sure how many commits to go back. Alternatively, you can instead of HEAD~3, simply provide the hash of the commit (or the reference like origin/master) you want to "revert back to" on the master (/current) branch, e.g:

git reset --hard a1b2c3d4

*1 You will only be "losing" commits from the master branch, but don't worry, you'll have those commits in newbranch!

WARNING: With Git version 2.0 and later, if you later git rebase the new branch upon the original (master) branch, you may need an explicit --no-fork-point option during the rebase to avoid losing the carried-over commits. Having branch.autosetuprebase always set makes this more likely. See John Mellor's answer for details.