Alternative to git rebase

Question

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:

1. git checkout testBranch
2. git fetch origin
3. git rebase origin/Master

I 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?

Answer 1

You can use merge instead.

The pros of merge: one has to resolve accumulated incompatible changes only between current final state of testBranch and current state of master (although conflicted places can be the same in terms of line numbers), rather than to re-apply each commit from testBranch over the new tip of master (this is how rebase works). The cons of merge: the history graph becomes more complicated, some people dislike such complex graphs, especially those migrated from "legacy" VCSes with simple tree-like history graphs.

Sometimes tools like git rerere might help, especially when one deals with a set of repetitive conflicts. But certainly it's not a silver bullet.

And yes, follow @SamVarshavchik advice: it's better to regularly track upstream changes and "keep on par" with them in your feature branch rather than to have a thousands lines conflict one sunny morning. Or not that sunny, or not a morning — actually it doesn't matter, because one have to spend hours, days or even weeks to settle it down.

Often it helps to split your huge feature branch into smaller pieces and push those changes back to the upstream as soon as possible. Thus your colleagues would use your code and your approaches, not inventing their own [conflicting] ones, so merges/rebases will be simpler for all parties.

Also it's useful to use a mandatory peer code review system in your project, even for commits in feature branches. Nowadays I'm a bit skeptical about human's ability to track down possible errors in complex code simply by starring at it. But at least all persons involved in development of a particular place of code are aware about proposed changes and can coordinate efforts in different branches.