My advice is more complicated.

First, I firmly believe that every project needs some kind of version control. Bitbucket allows free private repos, so I would use that to host your code.

Second, every project needs some kind of structure. You might consider running your project using Agile principles--if so, I recommend reading "The Art of Agile Development" as a starting point, and asking your coworkers if they are willing to buy into that methodology. Obviously, with just three of you, certain things like pair programming aren't going to work, but other ideas (like a card wall) might work well.

I recommend using something like XP for two reasons: first, it's really easy for the team to see where they are. Second, it's really easy to communicate to management where you are. Other advantages include having a common vocabulary to achieve agreement: rather than say, "I'm going to futz around with jQuery for a couple of days", say "Let's run a spike to investigate jQuery, timeboxed to two days." That work gets captured and documented, which is helpful.

But regardless of what project management technique you decide on, try to stick with it long enough to know whether you need to change it, and get as much buy in from your team as you can for whatever project flow you come up with. Since you aren't their manager, you need to all reach consensus before anything can be done anyway.

First, I firmly believe that every project needs some kind of version control. Bitbucket allows free private repos, so I would use that to host your code.

Second, every project needs some kind of structure. You might consider running your project using Agile principles--if so, I recommend reading "The Art of Agile Development" as a starting point, and asking your coworkers if they are willing to buy into that methodology. Obviously, with just three of you, certain things like pair programming aren't going to work, but other ideas (like a card wall) might work well.

I recommend using something like XP for two reasons: first, it's really easy for the team to see where they are. Second, it's really easy to communicate to management where you are. Other advantages include having a common vocabulary to achieve agreement: rather than say, "I'm going to futz around with jQuery for a couple of days", say "Let's run a spike to investigate jQuery, timeboxed to two days." That work gets captured and documented, which is helpful.

But regardless of what project management technique you decide on, try to stick with it long enough to know whether you need to change it, and get as much buy in from your team as you can for whatever project flow you come up with. Since you aren't their manager, you need to all reach consensus before anything can be done anyway.