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.
It all depends on how you want to organize your repository’s history, and what’s easiest for you.I’m personally a big proponent of using git rebase. For example, you could use rebase or even pull with rebase instead of merging. Of course, there’s plenty of different ways you could tackle this problem. If you’re confused about how this works, check out the History section of Git for Computer Scientists for some graphs on how the fetching and merging process works. Doing a pull usually only brings changes in from one source. How is this different from just doing a git pull upstream master? This brings in changes from two different sources: his own fork and the main repository (the upstream). Now git pu will grab all of the latest changes from both remotes, and then merge in the commits from upstream. Pu = !"git fetch origin -v git fetch upstream -v git merge upstream/master" Git remote add upstream git:///user/repo.git So, he’s created a helpful alias so he can merge in changes easily.įirst off, he’s got a consistent naming scheme for his upstream remote: This tip comes from Dav Glass, whose work on YUI at GitHub requires him to bring in commits frequently.
0 kommentar(er)
