I would suggest the following:
Editing the same files
First, use Git (or a similar concurrent versioning system). As long as you are editing different parts of the same files, you wont get conflicts. If you do get conflicts, they will be clearly marked as such.
Trying to manage a multi-developer project without Git is like trying to make a pudding without a pudding bowl. It is possible, but it's going to get pretty messy pretty fast.
As has been pointed out in the comments, Git is not a panacea, but combined with automated testing it certainly helps a great deal.
List all the features
Second, break the project up into user visible features. For example "when the user signs up, they should receive an email" or "The user can add an item". Involve all stakeholders here. Get everyone in a room, and have everyone shout out their features.
These should be user visible features, you can talk about implementation strategy later.
Write all the suggestions on index cards, even the dumb ones. Quickly rationalise the list to remove duplicates, and lay out all the cards on a big table, or even the floor.
Add in any additional cards that are needed. Say your application will send SMS text alerts. You might not know how to do that, so you have a question. Write "Investigate SMS portals" on a card. Likewise for any other big unknowns. You'll have to unpack these later. These features will probably not make it into your first sprint.
Now sort your cards into groups, shuffle them about, get a feel for them. This is your project scope.
Have a go at planning poker. Still with everyone together, give all the developers cards that say "1 point", "2 points", etc, up to "4 points". Also a "more" card. A point is roughly equivalent to an hour.
Go through the feature list one by one. As you read out a feature, everyone has to play a card. If one person plays 1, and another person plays 4 there's a communication problem there. One person understands the feature to mean something different from the other person. Have a discussion and work out what was actually meant and note it on the card.
If you agree that a feature is a "more", that feature is too large. You have to break that feature down. Do this in the same way as before.
As you have agreement, write the numbers on the cards in a different colour pen.
Points are better than hours
Using points instead of hours takes away the macho "look how fast I can code" thing that we developers often engage in. It's a subtle difference, but I have found it works rather well.
Now compose a sprint
A sprint is a quick burst towards a goal. Decide on the sprint length, perhaps 5 or 10 days. Multiply the number of days by the number of developers by the number of points per day.
Assume 6 points per day per developer initially. This is an achievable number. If you have 5 people, that's 5 * 5 * 6 = 150 points. In conjunction with all the developers and the management, pick features from the list, up to 150 points. That's your sprint.
Never be tempted to squeeze more in than will fit. Over-promising hurts everyone in the long run, including you.
You'll need to take account of dependencies here. For example, environment setup obviously has to be included in the first sprint. This is actually relatively easy to do when everyone is present. You have 6 brains in the room, all saying "this depends on this", etc. You can then shuffle the cards around to demonstrate dependencies.
Once you have your sprint, nothing can be added to it, it's locked for the 5 days. Feature creep will stress the team, damage morale and slow everyone down. Eventually, creep will stall a project. As team leader you have to protect your team from feature creep. If a new feature request comes in, it must be added to the next sprint. IF the next sprint is already full, something else must be taken out.
Never be tempted to squeeze in extras. Over-promising gives you around 1 day's worth of happy client, followed by 4 days of team stress, and eventually, most likely, several unhappy clients when the team can't deliver on time.
Now go to it.
Hand out cards, ask who wants to do what. You have full visibility on what is getting done, and you can count the points ticking down to zero. Have a standup at the start of each day so everyone knows who is working on what, and what has been done.
5 or 6 decent motivated developers working together as a unit on clearly defined manageable goals can achieve a pretty chunky amount of stuff in a 5 day sprint.
Make sure everyone can see what the status of the project is. Bluetack all the cards to the wall. On the left are cards that are not yet worked on. On the right are done cards.
When a developer is working on a card, they take it off the wall and put it on their desk. This maintains visibility, and keeps people from stepping on each others toes too much.
There are technological alternatives to index cards, but nothing beats having a massive paper display of the project status on the wall.
If possible, have everyone in the same room for the duration of the project. Have the stakeholders around as much as possible, ideally every day.
You can graph your points progressing towards zero on a burndown chart. If your line of best fit crosses zero before you hit your time limit, you are likely on track. If not you may need to let your client know now, before you get too close to the deadline.
If you're going to fail, fail early.
You can make a burndown using software, but I prefer just a big piece of paper on the wall. Draw and write all over it.
When you have multiple developers working on the same stuff at the same time, they're probably going to break each other's code from time to time. Communication and visibility helps with this, but you're probably going to want to introduce some technology to help with finding issues.
Unit testing is the process of writing tests for each individual part of your codebase (ideally each method). Your unit tests should be run often, with every save if possible. There are many tools that can help with this, for example Karma or Rspec.
End to end testing involves testing your project as a whole, treating the internals as a black box. Base these tests on your high level business requirements, for example: "The user can sign up" or "The user can see a list of items". Protractor is a nice example of an end to end web based testing framework.
There are whole books written on testing, but having at least some acceptance tests in place can help to make sure nothing gets broken as you work on your project.
Avoiding technical debt and getting to done-done
Technical debt is a concept that describes things that will have to be cleaned up later. A common source of debt is features that were marked as done, but which were never "done-done". A done-done feature is checked in to Git, has been approved by the stakeholder, and has a test.
Don't check your features off until they are done-done. Never massage the graph. Again, this hurts everyone in the long run, including you.
This is one reason why we initially only quote 6 points per developer, per day. Done-done takes extra work, but feels great and gives the team a boost.