I am new to git. Let's say, I have forked a repository locally from remote, and it is called localRepo. There are two branches Master and testBranch. testBranch is 100 commits ahead and 5000 commits behind. Changes were made to testBranch but never incorporated to Master. So I wanted to rebase testBranch onto master in my forked localRepo.
I did the following:
git checkout testBranchgit fetch origingit rebase origin/MasterI am experiencing several conflicts and I am solving it by hand using mergetool (kdiff3) and by saying which deleted or modified file to use etc...
Since it is around 5000 commits behind, are there possibilities for more conflicts to occur? If i resolve conflicts manually like this, I wonder how many days would it take! It would be very tedious and unpractical.
Am I doing it in the right way?
Is this the only way for this scenario? Or any other efficient way?
No, there is no alternative to rebase. It is what it is. Lesson learned: rebase early, and rebase often. Getting behind on your commits means that you are going to waste a lot of time, sooner or later. Two years ago I wrote and merged a 200-commit feature branch, that was developed over the course of six months. I don't know how many commits were merged during those six months. But I'm sure that they also numbered in the thousands. Had I waited until I finished my feature branch, and tried to rebase, I'd be in big trouble. But I rebased daily, and the eventual merge turned out to be a big, fat, nothing-burger.
If the hundred or so commits in your feature branch can be logically divided into small chunks, it might be possible to divide the rebase into phases. If you have several major checkpoints across your feature branch's hundred commits, and at each point your feature branch is fully-functional and testable, you might consider taking all the commits up to the checkpoint only, and then rebase just those, and then test them. Then, once you've tested that the initial chunk of your commits are working after the rebase, proceed and rebase the commits until the next checkpoint.
When you rebase everything at once, git will stop only at each commit that fails to rebase. At least this way you have more control over the process. You can stop, and pause, at predetermined checkpoints and do a extensive regression test on the rebased changes, then proceed.
Note, however, that for this to work you have to be perfect in keeping track of all the commits on your feature branch; which one have been rebased, and which ones haven't.