Did this subject ever get you interested but you didn’t know where to start and what to do about non-fast-forward errors? Let’s jump right in.
-
How do you restore your neighborhood branch to a pushable state?
Now, we’ll examine how to get the local branch to a condition where the remote won’t refuse a push.
- No rebase(s): merge the remote branch into local
updates were rejected because the tip of your current branch is behind
So, is it as easy as just doing it?
git pull
including resolving any conflicts that could occur.
If someone has updated the remote, we shouldn’t proceed with this. Because the histories are distinct, a merger can negatively impact the histories. A strange history with identical commits in two places and a merging commit will result.
Continue reading for answers to the situation of “remote has been rebased.”
-
No local commits plus remote rebase: make git overwrite files when you pull
If you don’t need to make any adjustments that aren’t listed on the remote, perform the following:
git reset --hard origin/branch-name
Although this is very rarely the case, it provides a route to the next two solutions.
Options 3 and 4: save local modifications elsewhere (the git stash or another branch). The command mentioned above was used to reset the local branch to the origin. They then send them up after applying any local changes once more.
-
Local commits plus remote rebase: soft git reset, stash, “hard pull,” pop stash, commit
Say you have made some local improvements (maybe just a few commits).
Doing a “soft reset” is an easy way to put the information from 2. to use.
Options to “soft reset”
Option 1, using “first-commit-sha” for the first commit you’ve added:
git reset <first-commit-sha>^.
Option 2: You can also use the formula below if you know how many commits you’ve made; just swap out 3 for the number of commits you wish to “undo”
git reset HEAD~3.
Run git status to verify that the local commits we just “undone” have left unstaged (i.e., “modified”) file modifications.
You can save your changes to the stash
Put them in the stash by running git stash (for more information see git docs for stash).
The un-staged (“changed”) files are no longer present, as can be shown by running git status.
git stash pop
Now, you can use git add (ideally with the -p option, e.g. git add -p.) and git commit to add your local changes to a branch that the remote won’t reject on push.
Git push shouldn’t be denied after you’ve added your modifications.
-
Local commits plus remote rebase 2: checkout to a new temporary branch, “hard pull” the primary branch, then cherry-pick from temporary onto the primary branch
Branching off of the local branch and re-applying the commits of a branch that has been “hard pulled” is an alternative to using stash.
Create a new temp branch
We’ll start by establishing a fresh, temporary local branch. Assuming we began on branch branch-name branch (if not, use git checkout branch-name), we can perform the following actions:
git checkout -b temp-branch-name
By doing this, a new branch called temp-branch-name that is a copy of our changes in a new branch will be created.
Go back to the branch and “hard pull”
Returning to the branch name, we’ll now replace our local copy with the remote one:
git checkout branch-name
-
Selectively commit changes from the temporary branch to the local branch.
We should now return to temp-branch-name and obtain the SHAs of the commits we wish to apply:
git checkout temp-branch-name
Followed by
git log
Identifying the commits we wish to apply (to exit git log you can use q).
Cherry-pick each commit individually
Take the example where we wish to apply commits “commit-sha-1” and “commit-sha-2.”
The remote version has been reset, thus we’ll move to that branch by using:
git checkout branch-name
Then, to apply those commits, we’ll use cherry-pick (see cherry-pick git docs):
git cherry-pick <commit-sha1> && git
Cherry-pick a range of commits
If your commits are consecutive and you have a lot of them, you can use the following (for git 1.7.2+)
We’ll ensure that we’re working from the branch that was switched over to the remote version by using:
git checkout branch-name
Credit goes to François Marier for “Cherry-picking a range of git changes” in Feeding the Cloud for git versions 1.7.2 and up.
git cherry-pick <first-commit-sha>^..<last
The local branch should now be able to be pushed to the remote without being refused using git push.
Photo credit: The feature image has been done by Roman Samborskyi.
