I’m a little confused. There’s no such thing as a “forked” branch. You can fork a repository, but not a branch. So leaving aside the confusing “fork” terminology, I think you’re asking: “If I check out a new branch and pull from
master in the source repository into my local new branch, should I update all my local non-default branches or should I update my local default branch too?”
If that is indeed what you’re trying to ask, I have to give a rather unspecific answer of “it depends”. There are reasons to merge changes from one branch to another and there are reasons to not merge changes from one branch to another. It is entirely dependent on your workflow, which is why Git can be infuriatingly complex at times because it doesn’t prescribe one style of workflow over another and essentially supports them all.
An example reason why you might want to merge the latest
master changes into your local working branch is that your local working branch changes are intended to be shipped along with the latest version of the project. Conversely, if your local working branch is porting a fix from a later version into a previously released version, common when working on backporting a security fix from v2.x to v1.x of many projects, you may not want to merge the latest
master changes into your local working branch.
So, I suppose a more meaningful answer to your question is: don’t merge the latest
master changes into local branches by default and only merge them when you have a reason to.
I hope that helps!