You should use the GitHub branches.
GitHub gives you the possibility to create an infinite amount of branches, but why should you use to do that? After a talk I had at GitHub Amsterdam, this became clear to me and I would like to share it with you because it improved my working process.
At GitHub, there’s a branch for every adjustment there’s made. With the simple reason to separate the little projects from the main branch. These branches are called: Feature branches and as the name probably will tell you, you create a new feature in this branch. After the feature is done, you can request a pull request, get some issues, fix them and merge your new feature with the bigger branch. After this, you can probably deploy a new version and you’re done.
Of course, this is the ideal world and not everybody lives in that world. So what if you work at a company who don’t use issues, pull requests and multiple branches, why would I still start creating feature branches?
Because of Maintainability, Structure, a better Overview and a Great Modular Approach. If you develop a new feature, adjustment or every other minor change, on a new branch, this is separated from the other processes. You can simply develop your new thing, pull the main branch and push your new feature. This will create a log of what happened when and gives you a great overview of your entire project. With that, the structure of your project improves and with that the Maintainability.
I’ve used this at my latest project and will show you how I did that and what you should do different if you will use it.
This is how my structure goes. There is one master branch and one develop branch. The only branch who is allowed to talk to the master branch is the develop branch. The only thing the live server is allowed to pull is the master branch. This means every branch can be merged into the develop branch, tested and pushed to the master branch after a GO. This prevents bugs on the live server.
Here’s an illustration of this process:
Client: “That thing we did with the flying animation needs to go”. Now if you committed your whole project on one branch, this will be an issue! Not if you’ve just created a branch for this bit. You can easily see or redo the changes from this branch and the “flying animation” is gone.
A better Overview
This image shows all the merges into different branches. This contributes are only from myself, as I was the only one working on the project. But if you work with two or multiple developers on one project, this system will provide you with a very clear overview of the entire project
A Great Modular Approach
Tip: If you don’t use Git in your projects, please start using it!
Do’s and Dont’s
The first thing you need to do is create your first feature branch. I’ve tried to use a lot of different branches for every new feature I started, but basically I was setting up the routes on the server. So call this branch ’server-routes’ and start with your feature branches if the absolute core is set.
You will end up committing something in the wrong branch. Don’t worry about that too much. It happened and just add this as a message to your commit message. One tip, if you use Atom as your Code-editor, in the right-bottom corner it will tell you on which branch you are and Sublime has a plugin for this. It might help you!
If you find out that your branch is too big and it needs to be more specific, commit your branch and be more specific. There’s alway’s the possibility to remove a branch!
Thanks for reading!
Thank you for reading and if you have any feedback or questions, please add a comment and I will get back to you.