Version control will only help to the extent that you will be able to go back to previous (hopefully working) versions.
It will not help with botched deployments and changes.
You need to have a test environment - a web server that you can put the changes on and test them and only when happy, push to a live (publicly visible) web server.
For a team of 3-4 devs, you're proposing WAY too many branches.
Every branch you create is additional overhead that comes with a cost (time spent merging, keeping track of what's where, etc). You need to make sure that the benefit you get from having a branch outweighs the cost.
Keep in mind that the only real benefit to a branch is code isolation. That means you need a concrete reason to want to have the code isolated.
Having a separate release branch for every sprint is insane. Why do you need the code from one sprint isolated from the code for the next? Why not just have a single stable release branch that gets carried forward with each sprint?
If a change is estimated to take more than a week then it should be done on a branch, with regular merges from the trunk into the branch to stop the two going out of sync.
Almost any non-trivial new feature is going to take at least a week in real time after you account for development, developer testing, daily interruptions and other activities, etc.
Also, what's a "regular merge"? Daily? Weekly? Every merge you do takes time - you need to make sure the target merge branch builds & runs after your changes. On a small team, frequent merging is a lot of overhead.
We have a team of 4 developers working on a 1+ million line codebase and this is how we operate:
- Main branch where all development is done
- One branch per major release (done about once per year)
The one major rule is: don't check in code that doesn't build.
That's it. Simple, easy to understand, gets the isolation we need (at any time we can create a release build for any version).
The upsides to having all development work done on one branch:
- Developers are always in-sync with each other. No painful merges because two developers were off on their own branches for weeks creating incompatible changes.
- Broken builds are found on the same day. We have a nightly build that runs the latest code on main. If someone does check in code that doesn't build for some reason, we will know right away.
- With everyone always working on the same code, in increases the chances of a bug being found sooner rather than later.
- No merge overhead other than targeted fixes to release branches. On a small team, this is the big one.
Best Answer
Yes.
All it takes is a single mistake and you'll be kicking yourself for it. You're also in the position to choose which version control system (VCS) is used. If there is any possibility that you'll work in a development team in the future, this is a great time to give yourself hands-on experience with a VCS. SVN and Git (or Mercurial) would be great starting points and should only take a couple of hours to grasp the basic commands in each VCS.
Now to debunk what the negative points...
The only resource required is disk space. Since this is a small percentage (smaller in Git than X) of your total code, I don't think this will be an issue. It doesn't cost any money either.
There will be time required to learn it, but it is only a few hours for each of these (as mentioned above). On the longer term, it has the potential to save you an infinite amount of time (and so much more). Once you've mastered the basics of a VCS, it will be far less finicky than performing the local backup you have in mind.