Versioning methods


Most developers over the last 5 years now use versioning software to manage code for their projects.
They do this because it makes it easier to see the timeline of any work completed and if you have multiple developers working on the same project you can merge the 2 sets of code together easily.

I use GIT as my prefered versioning software as I do think it makes life allot easier than other solutions out there, but these rules will work with any other system too.

NEVER WORK ON OR COMMIT ANYTHING INTO THE MASTER OR TESTING BRANCHES

You always pull the latest version of the branches you are working on before starting work on any day.
At the end of everyday your code is to be commited to your branch along with adding comments to the tasks you are completing on your tast list.

CREATING A NEW BRANCH

Always create a new Branch from Master only.

Overview of the GIT repository:

Master: Main branch and the live site (Only to be edited by Administrators)
Testing: Testing branch for testing.mysite.com (Only to be edited by Administrators)
Hotfixes: Hot fixes required on the live site (Developers). Naming convention: hotfix-*
Features: Feature updates to the website (Developers) . Naming convention: feature-*

Once your hotfix or feature is complete, email the lead developer stating that this update is ready for pushing live along with the name of the branch.
Once your branch has been tested, approved to go live and merged into master, this branch will be deleted to keep branches tidy.

This image should help you understand clearly how you code gets pushed live.

This solution gives you the freedom to manage big code updates simultaneously with multiple developers but still allows any quick fixes to be added without causing real problems to other branches.

Leave a Reply

Your email address will not be published. Required fields are marked *