Let's suppose commits D and E are two megacommits from a colleague refactoring something your code is dealing with. However, this gives you loads of conflicts. What you want to do ultimately is to rebase onto Z. Imagine the tree looks a bit like this: A - B - C - D - E - F. However, if a colleague has been refactoring whilst you've been working, sometimes what you are best doing is as follows. If you've already done that, you are probably going to have to bite the bullet. I'm guessing you should be down to 10 or 20 commits when this is done - far more manageable. You can take the opportunity to fix these.
Inevitably when I do this I find stuff I did wrong, or could have done better, even if it's 'only' code formatting or commit messages. In particular, if you have internal merge commits, flattening these is helpful. Key backup branches ( git branch) and git diff to those after each commit to check you've not changed anything. You can take the opportunity to change your commit logs too. Make sure you have the minimum number of commits and that each of those does something independent. Rebase it onto its existing base, but use git rebase -i to interactively squash together and reorder the commits. So the answer here is to tidy up your commit history before you rebase onto master. If only you had one single commit that modified function X, you'd have 20% of the work to do. Perhaps you've modified function X 5 times within the commit history, and each one of those commits is going to cause a conflict. However, from 100 commits in two weeks, I'm guessing your commit history does not look like that. If you have a beautiful clear stream of 100 commits that never modify the same code twice, I'm sorry, but you are stuck. Four strategies might be useful: Reduce the number of commits to rebase This depends in part how you've done your 100+ commits and what's been happening in the meantime.
0 kommentar(er)
