The long-running feature branches are indeed the challenge in this scenario, but this is a common issue for which Git provides multiple solutions.
As others have suggested, one way to minimize merge conflicts is to regularly merge the development branch back into any previously-spawned feature branches.
This ensures that feature branches contain the latest upstream code in addition to the feature-specific changes, and prevents surprises later when the feature branch is merged to the development branch, as any conflicts are resolved within the feature branch rather than waiting for the final merge to develop.
However, this approach tends to create a rather chaotic revision graph, as relevant changes are interspersed with multiple merge commits, which can make it difficult to focus on the changes in the feature itself.
Where a cleaner history is preferred, feature branches can be rebased onto the development branch, effectively snipping them off from the outdated point where they initially diverged, and stitching them back on to the tip of the development branch with the latest changes.
Git novices may find rebasing difficult to grasp, but the commit graph helps to visualize the results, and Sourcetree's interactive rebase tool guides users through this process without touching the command line.
Atlassian provides a dedicated tutorial with good explanations on the differences between merging and rebasing:
Hope that helps,