Git branching strategies with a small team to develop a Drupal site

We're a small team (5-6 developers) building a Drupal 7 site. Previously, we've used Features (https://www.drupal.org/project/features) to export our configurations from development to production. We've relied largely on assigning developers discrete, unrelated tasks.

Our upcoming work has distinct, but related development. For example, I anticipate we'll need to add fields that will be used by two different tasks (for example, think about a date field for an event. One developer is working on the email invite and the other is working on the event display page). If we are able to anticipate this overlap, we'd be able to do this before either starts work.

However, if we don't realize a common need until after work has begun in separate branches per developer/feature, this becomes trickier. I believe that we would need to merge their branches together to access the common code-which defeats the point of us having separate branches in the first place.

Curious for what you'd suggest or has worked well in the past! Thanks!

Note: I've identified these potential solutions, both with drawbacks:

• Cherry pick commits. While this could be helpful, it's also likely that a cherry-picked commit will include extraneous changes beyond the narrow scope needed here. And it's just as likely that the single commit won't include all of the changes necessary (For example, if one commit created the feature, and a second created the field, you'd need to cherry pick both commits). This all seems to head for a merge headache down the road.

• Create a folder within sites/all/features/ignore, manually transfer the needed features there from the other branch. Include this directory in .gitignore. I don't like that:

1. This has our team sending features files all over outside of git,
2. That it could introduce dependency errors if features are changed in the original, but not updated in the other places that they are used,
3. That users may make changes to the ignored features that aren't moved into git,
4. That switching between computers/development environments would lose these files
5. That all related branches would need to be merged before deploying to production (which again, undermines the point of branching since these branches are now dependent on each other and would have to be released at once, rather than when ready/needed).

• Another option is to make the change (export the feature needed or cherry-pick commits) to the parent branch (e.g., Develop or Develop-Feature) so that it's available to all child branches.