If you're working with Git, you should try out Pull Requests.
In summary, you first merge the master branch into your current working branch. Any merge conflicts will be in your local branch. This is nice because your master branch is never broken. If you really screw up, you have you local commit that you can revert to.
Once you finish the merge, you ask someone else on the team to review and merge your branch into the master branch. Never merge your own! So long as no one sneaked in and did another Pull Request, you're guaranteed to merge successfully. Since everyone is aware of the Pull Request, you shouldn't have multiple people merging into master at the same time anyway.
Once you get used to this process, you should try to merge as often as possible - sort of a poor man's continuous integration. The less time between conflicts the better. You'll identify when two people are duplicating effort and they can team up. Some places will merge every time they complete a requirement, which could be every couple hours. I recommend merging at least once a week; otherwise you need to break your tasks out better.
I typically create one branch per task. Git is nice because it distinguishes between local commits and pushes. This provides some of the benefit of each person having their own branch without all of the complexity.