Here is the second problem did you push your branch to origin before you did this rebase? If so, your branch on origin is still pointing at those old commits. The old commits are still there, but because no branch points at them anymore, they will eventually get cleaned up as if they never existed. If you chose to rebase, then your branch now points at the tip of those new commits that rebase copy/pasted for you. The latter literally replays the commits from your branch on top of master, like copy/pasting your work and making new commits. You have 2 options: merge master into your branch to get the new commits, or rebase your branch on top of master. Here is the first problem you created your feature brach from master, then master changed. To fix this you just need to pull down the changes to master. It is accepted, and master is now updated to include their changes.Īt this point, your local git repo is out of sync with origin. They finish their feature and push it to the remote named "origin" and create a pull request to merge it into master. Someone else also created a different feature from master as well. So you created a feature branch from master. It suggests keeping both so you don't lose data by accident.
Git doesn't know if you want the old commits (on remote) or the new ones (on local). Tldr Rebasing doesn't move commits it makes new ones. What you should do depends on your workflow. We have specific branches that we don't typically allow force pushing to (develop and master) so those aren't usually rebased. I usually recommend this, though, because the workflow we use encourages people to treat feature branches as volatile and may change. This is dangerous because if someone else has already pulled your branch, their history won't match with yours. It's almost the same as deleting the remote branch and making a new one with the same name. I don't usually recommend this because rebasing usually means you don't want the old commits, you want your modified history.īy force pushing instead of pulling, you're telling Git to ignore the old commits and use your new ones instead. Git will automatically resolve this with a merge commit.
In your example, it's the 45 commits.īy pulling, you're telling Git that you want the old commits and the new commits. These are the new commits created by the rebase, the commits you rebased onto, and any new commits you've added since. Since all the commits you've created on your local branch during the rebase are "new", Git will also tell you that you have commits on your local that aren't on your remote branch (your branch is ahead of remote). If you've set the remote branch as the upstream of your local branch Git will tell you that you have commits on your remote branch that aren't on your local branch (your branch is behind remote). Your remote branch is still pointing to the old commits. Git identifies commits by their hash so even though your commits might have the same deltas or commit messages, Git sees your new commits as entirely different commits from your old ones. Since each commit has a new parent, Git will recalculate the hash of each commit in the rebased branch.
When you rebase, you're changing the history of all those commits.
0 kommentar(er)
