Create a new branch from master for each of your stories/features.
Before merging each branch back, either merge master into that branch or rebase your branch onto master. The latter has my preference, but in the end the outcome is the same.
You are going to get conflicts, there is no way around that. However, you want to solve conflicts in your branch; not in master. This way, you can test your branch after resolving the conflicts before merging it into master.
I'm assuming you want to start the new user_story_2 branch on top of the work you've done in user_story_1. Here's the workflow I use in this sort of scenario:
Open Pull Request for user_story_1:
* (user_story_1)
*
/
* (master)
*
*
Create new branch user_story_2 based on user_story_1:
On branch user_story_1, git checkout -b user_story_2.
Make changes to user_story_2.
Once user_story_1 gets merged into master, switch to user_story_2 and do git rebase -i master.
This should show you a list of commits on user_story_2 that you want to include in the rebase. Delete the top few commits that came from user_story_1.
The rebase should complete cleanly unless master was updated with other changes. Now you have user_story_2 rebased on master and only having its commits.