If you're still in that state you can actually elect to skip those commits as you no longer need them, or just quit where you are: git rebase -quit This explains why you already saw the changes from f1 and f2 there, but it was still stuck on trying to replay the original f1 and f2 thus it had conflicts again because the merge commit that resolved the conflicts last time isn't being replayed during the rebase. (Had you added the option -i to the rebase you could have witnessed it.) Presumably commit m4 didn't introduce any conflicts with f1' and f2', so replaying them as "1 of 4" and "2 of 4" went just fine, and at that moment your temporary branch looked like this: m1-m2-m3-m4-f1''-f2''
When you rebased onto master a second time in step 5, you now have 5 commits that aren't on master, and, when you rebase the merge commits fall out by default, so only the 4 commits will be replayed. After resolving them and completing the merge, your branch probably looked something like this: m1-m2-m3-f1'-f2'-MC When you pulled, that merged in the original versions of f1 and f2 again which aren't compatible with the new state, so you had conflicts again. Since you had conflicts replaying f1 and f2 on top of m3, after resolving them your new state is compatible with f1' and f2' only. The fact that you didn't do that explains everything you witnessed. Then you can force push your feature_branch to remove the merge with the old version of those commits. To prevent this next time, as mentioned in Phillipe's comment, after rebasing your branch, if you've already pushed it before, don't pull like Git tells you to, but instead you should use git push -force-with-lease.įor now you can use git reflog to either find f2' or even f2'' and then git reset -hard. Instead you want to force push after purposefully rewriting your branch, such as with amend, or rebase. By pulling here you end up with duplicate versions of your commits. When Git detects this, it always tells you to pull and then push, but in your case, you don't want to pull because that will merge the old version of your branch back into your current, better, version. This is because origin/feature_branch has commits f1 and f2 and your local branch no longer has those commits, since now they are f1' and f2' which are different commit IDs. Your branch and 'origin/feature_branch' have diverged, and have 3 and 2 different commits each, respectively. Now when you tried to push, you probably saw a message like: each has a new commit ID, and in this case also a new parent commit ID, and committer datetime, etc.) (Note the "prime" here in f1' and f2', which is used to signify that they are like f1 and f2 but slightly different, e.g. In step 3, after you rebased feature_branch onto master, feature_branch looked something like: My understanding while playing the commits f1 and f2, i am supposed to get same conflicts which i had got already during step 3(consider in m4 there is no changes in files which f1 and f2 have). While f2 is being applied it gets conflicts again.
I fixed the conflicts and continue rebasing. While applying f1 it get merge conflicts with changes in files due f1+f2. UP TO THIS I AM PEREFECTLY OK.īut just before git apply applying f1 and f2 one by one (as part of rebase), the local workspace folder files has already f1+f2 changes ( This is confusing). In step 5, I have observed that feature branch get m1, m2, m3, m4 in correct order and start applying f1 and f2 one by one on top of that. Step 5: Rebase feature_branch again with master. Step4: Now a commit of m4 is made on master by some developer I did pull and fixed some merge conflicts again before pushing changes to feature branch. Step 3: I have rebased feature_branch with master (using command git rebase master)so that feature branch have now commits in the order m1, m2, m3, f1, f2 (I fixed some merge conflicts. Mean time some other developer added commit m3. Step2: Created a feature branch ' feature_branch' and added commit f1, f2. I have a master branch with commits m1 and m2. I saw some behaviour (not developer friendly in my opinion) with git rebase.
0 kommentar(er)
