I am trying to sync my fork with upstream.
git rebase upstream/master
But sadly, I found that there are 100+ of my local commits, and every one of them need manually conflict solving.
One of idea I am thinking is I can squash all local commits into one, then rebasing only one commit will be easier. But this is the last thing I want since I really want to keep all my commits' records.
Is there anyway to rebase huge commits with less effort?
I think a merge is actually what you want here, not a rebase. Resolving the merge conflicts will be equivalent to what you would see if you squashed all 100+ commits to a single commit, and then rebased that commit. But with the merge, you will preserve your work-in-progress history, as you desire.
Rebase is nice when you have just a few commits to sync-up with the latest work from your peers, or have a specific need to rewrite history, but when you have diverged by 100+ commits, you've created a use case that would more commonly be handled with a branch. Syncing up via a merge commit I think makes perfect sense in this case.
If you really need to be the only one to whom your work-in-progress history is visible, you could create a local branch (git branch <my-true-local-history>) pointed at the head of your local work-in-progress to preserve a named reference to the commit, and then perform a squash merge (git merge --squash) which will still create a merge commit, but will collapse your work-in-progress commits down to a single commit (the local branch you created earlier will still point to the true detailed history, however).