If you have local changes in that branch which you don’t wish to lose, it gets more complicated. Replacing your local version of topic with the remote, git fetch git checkout topic git reset -hard origin/topic. If someone has rebased a branch you have a copy of locally, you will then need to perform the inverse of a force push. After performing a force push, the only way to recover the deleted history is via git reflog.
You may wish to first review your branch history with git log and execute your test suite to ensure everything is as expected. However, if you are working in your own feature branch, force push simply serves to make the remote branch match your local copy and should not harm other users. It is true, you should avoid force pushing to master, or to change/delete any commits relied on by other users (without their approval). This replaces the remote topic with your local topic.įorce push is only ever used to rewrite history, for this reason it has a bad reputation from people using it without understanding what they’re doing (and inadvertently deleting important commits). Therefore, in order to push the rewritten history to remote, force push must be used git push -f. This is why git believes you are behind and suggests you git pull, your branches diverge at commit E rather than the head of the remote topic. When you attempt to git push, topic on remote is D-E-A-B-C, whereas the local topic is D-E-F-G-a-b-c. As commits have been deleted, history has changed! This is why git sees commits a, b, c as completely new commits, whereas A, B and C no longer exist. Their commit hashes have changed, so git no longer sees them as the same commits. However, as the parents of commits A, B and C have changed. If we call git merge topic, whilst the current branch is master This essentially creates a new merge commit with parents from both of the branches being merged. If the branches master and topic both contain new commits, a true merge will be applied. There are actually two types of merge which can occur True Merge Git merge incorporates changes from the named branch to the head of the current branch. The rebase has intentionally changed history which leads to this disagreement between the local and remote copies of the branch, performing git pull at this stage will (redundantly) merge back in the the commits that were just rebased. However, this is not what you want to do. Helpfully git bash suggests you should use git pull first, to include the remote changes, before you git push. The classic problem is that after performing git rebase, you attempt to git push and your changes are rejected as your local HEAD is behind the remote HEAD. This can easily lead to people misunderstanding how it works, which can subsequently lead to problems. Whilst it can be used in place of git merge to combine branches, it operates differently. I’m personally a big proponent of using git rebase.
0 kommentar(er)
