any new story might influence the outcome or might have a connection to other stories (both on functional and technical level), so adding new stories to a sprint will potentially cause more issues/conflicts than prevent them.
I am assuming here that you are talking about merge conflicts. The easiest way to prevent these is by splitting stories based on technical dependencies (e.g. developer 1 works in module A, developer 2 in module B) and see if it's possible to work together. When working together with multiple developers on the same story the risk of overlap/conflicts will inevitably be higher, so this might be difficult. Also, if developers communicate among themselves as soon as a commit has been made, the others can immediately push the “Update from teamserver” button to retrieve the changes instead of waiting until they commit themselves. This will prevent longer periods of inconsistent models and thus prevent conflicts.
When it comes to handling merge conflicts as they arise: The best way to deal with them is to resolve them together with the developer that caused the conflicting commit. In case of domain model conflicts this is usually the only and fastest option, because each developer will know the impact/functionality of their own story best. In addition, when it comes to microflow or page conflicts I always select Duplicate, then "Resolve using theirs", then put my own changes back in. What I don't want to happen is that I undo changes from another developer, because without their help it will be much more difficult to determine whether or not my commit will cause any side effects..
Last but not least, merge conflicts are easily introduced when renaming entities, attributes or associations. If a developer plans to do such a thing, it is best to have a single developer do this at the beginning of a new sprint and commit the changes before any development takes place.
That said, If a developer has finished all his/her stories for a sprint, he or she could also be involved in reviewing the code of stories done by other developers, spend time on refactoring existing code or analyzing/elaborate stories for the next sprint together with the product owner.
Moving on to the next story on the project backlog should not be a developer’s primary reflex. If you do, you are leaving behind a teammate that struggles to meet the sprint end. And it ignores that you, as a team have not met your sprint goals yet. Working together can be done in several ways, pair-programming being one of them. Prepping test cases another. Peer reviews a third. Documentation too.
Shared development whereby you divide work into small parts is possible as well but only helpfull if it is possible to divide work into bits. Which is more difficult when your app is a spagetthi, and more easy when it has a clear structure, testcases and adheres to the SOLID-principles where possible.