(Edit, : see also this answer to Why is git rebase discarding my commits?. I have the following in my ~/.gitconfig: Note: My git pull -rebase here should actually be read as a -rebase=preserve, if that matters.
When it does work for a commit, though, it works every time. Unfortunately, this is not 100% reproducible for all commits. This seems to directly contradict my understanding of how git pull works, unless git fetch. The commits have been applied correctly and my new commits on feature are still present. (from branch feature): $ git rebase master Now, if I reset my position, and instead do the following: (from branch feature): $ git reset -hard # rewind to before second git pull
(from branch feature): $ git pull -rebaseĪt this point, the few commits ahead I was on feature have now been lost. (from branch master): $ git checkout feature Sometimes, I will lose commits by running the following sequence of steps (from branch master): $ git pull -rebase branch feature is set up to track local branch master, and ahead of master by several commits.branch master is set up to track origin/master, and is behind master by several commits.branch origin/master references branch master on remote origin.In my workspace, I have the following setup: I seem to have found some case where this doesn't work as expected. (from branch master): $ git rebase origin/master And actually the changes made in commit #1 and commit #2 were still available.According to my understanding of git pull -rebase origin master, it should be the equivalent of running the following commands: (from branch master): $ git fetch origin It was as though both commit commit #1 and commit #2 were gone, and left with commits from master branch, because git did not rewrote them when rebasing feat/a. In cases like this, git would not rewrote the commits again, if git could figure out whether it was a duplicate: However, if you look at the history right now, the commit commit #1 and commit #2 was written twice, first the original commit, second the rebased commit. So what happened was all the commits in master after branching out feat/a all the way to the newly rebased commits in feat/a were rebased onto origin/feat/a: $ git rebase -onto origin/feat/a origin/feat/a feat/a She rebased feat/a on top of origin/feat/a, she ran: So, the first thing she did was to git rebase feat/a on top of master:
To understand what happened, I decided to draw diagrams to visualize what had happened: So, we expected to see commit #1, commit #2 at HEAD after rebasing onto origin/feat/a after the git pull -rebase, yet, the only commits we saw were a bunch of commits from the master branch. Then, instead of git push -force my local feat/a to remote origin, I git pull -rebase origin feat/a.Īnd, my commits on feat/a, eg commit #1, commit #2 were gone! I noticed that master branch has new commits, so I pulled master branch, and rebased my branch feat/a onto master branch. I branched out feat/a branch from master and made a few commits ( commit #1, commit #2). I found that her scenario was interesting, and decided to write it out here. She somehow ended up with a messed up git history with git rebase, and she couldn't comprehend how she ended up there. At the end of the talk, one of my colleague approached me and asked me about git rebase.
Last week, I shared about git commands at Shopee React Knowledgeable.
0 kommentar(er)
