Getting started with Git branches (I)

Branches, they can save you serious headache, waste of life and a horrible feeling of frustration. With Git, the possibility of creating different branches gives us an easy way to implement new code, new features and everything without modifying our production branch or Master Branch. If you never used a Control Version Software like Git, probably you’re thinking right now Why in hell I would need something like that?, well just remember, always think in the bigger picture and not just in the index.html we are using as example in this course.

Every repo should have at least two branches, the production one (master), where the stable code and final features are included (Yep, even that one you thought nobody would like but all the community is dying for it!) and finally, another branch that includes (obviously) the code from master plus all the experimental features and modifications (we will talk about the way Git has to classify branches and the naming rules) that we are currently testing, in other words, is not stable for daily use.

Like we explained in our first article for this What is Git?, one of the best features of Git are the branches and absolutely the speed, but comparing the way Git has to deal with the branches for our project is amazing. Creating a new branch is really easy, with a simple command Git creates a new branch, but not only that, we can merge two branches into one, create a new one copying the core (or source code, sorry I just got excited with this one ;P) and all this with a flawless speed which makes Git the best tool for developers.

Let’s get dirty

You have your client’s website in the master branch and he just called you because all his family are together discussing about the design and they decided they would love to see the website with a bigger font and they want to see it now that they are all reunited. Customers are always right… keep that in mind… What you can do now? You modified almost all the files with new features or with changes that aren’t ready just yet and if you just throw everything to the bin and modify just the font for the client probably is going to take a huge effort to recover everything and put things back into place.

That’s why at this moment you need a new branch header-feature, for all those changes you just did and you want to keep to show them to the boss in the future and then you just need to create a new branch based on master, something like changing-font-size for the change that you’re requested. Whenever they decide it looks perfect (WARNING! Can take a while for this to happen :D), the branch changing-font-size will merge with the master branch (and with the header-feature one), this way, we can return to our heaven of new features and keep working hard on the new implementations we working on! (Just like if the client never called us!).

Now that you found out why you started dreaming with Git a few weeks ago, in the next article for this course we’ll explain how to make all this theory into practice ;P

And remember… never stop programming!