Why I am using git flow and you should too

I have learned many things in only 3 months real Rails Engineer(not just on tv) and I have been a slacking a bit on sharing those skills due to the increase workload I continue to take on. I did want to take the time and share on `git flow` and why I am using it on my overhaul of my breakable toy app, Chuych.

While attempting to work on my chuych app in the past 3 months I have notice that my commits are a bit all over the place and I lack the focus to complete anyone thing, for example sticking to one design. This is why I have taken it upon my self to use git flow (What is git?).

 My goal has been to give my personal projects more of a focus lately since they have been ignored. I spent a lot of time trying to get up to speed in Ruby, Javascript, and even learn iOS on the side. I can say I really lost focus on maintaining my own code portfolio. I have however been taking work home and spend a couple hours on the weekend working through refactoring and bug tracking in my work code.

I have slowed down on my learning of new skills and languages and restricting myself to only learning things that will increase my productivity at work and make my chuych app more robust (This will not effect my iOS learning). I have spent the past 2 weekends building out my test suite and it is at a point where I can no just add test when I implement new things.

Git flow  is feature of git where you can speed up your workflow, in the command line, by creating structure in your branches/commits with shortcuts. This feature will create a branch, merge a branch, and close a pull request in 2 commands. It is not uncommon for someone to work on their personal app and commit and push everything on their master branch. There is no shame in this if you do so; I was doing this up until last month. I am now using git flow to create separate branches to organize my thoughts and focus on one feature/fix at a time. This really helped me finish the last of my testing and will hopefully help me build out my design stylesheets.

If you learned rails through any tutorial they team you to commit as soon as you are done with a full feature or full programming thought. They sometimes briefly teach you about branches, but from my recollection, it gets abandoned rather quickly in the tutorial, or at least I abandoned it. It really isn't necessary to be so verbose in your branching your commits, but for apps you would like to keep around for awhile, structure is what will keep your sanity.

My recommendation is to try using `git flow` for one feature of your site, if you are not already using a similar method, it will bring sanity back to your app development just as it has mine.

The Process:

To begin you will need at least 2 branches created in your app. I named one master and the other develop, but feel to use any naming convention.

  Master Branch - This branch is standard, especially using github and coming from tutorials. I believe most Rails developers and even possible back-end git users use this branch name. If you are using heroku or another deploying method, it can be deployed from here.

  Develop Branch - This is the branch where all you code will be merged to first and tested.

It is important to keep master separate in case you merge a breaking changes or something goes wrong, the merge history should be primarily merges from develop unless its a hotfix (to be explained later).

You can also create staging, release, and QA branches but I am keeping it simple for now and suggest the same.

Install:

There are complete git flow installation instructions on the web but I will provide the cliff notes.

Start by type `git flow init` in the command line and proceeding with the steps prompted in your terminal. They will ask what branch your feature will be merged to, my recommendation is to use the defaults on the screen and the develop branch to merge to.

Workflow:

Again there are many workflow examples on the web but I will provide the cliff notes.

In my current we follow the current structure.

1. Create a feature branch `git flow feature start <desired_feature_name>` while on the develop branch. What ever branch you are on will create the new feature branch, so make sure you are on the correct one.
2. Push the branch to git `git push origin <new_feature_branch_name>`  this will create the branch on github, be sure your git remote is set or you will be prompted the first time. 
3. Open pull request, on github you can use create a pull request compared to develop for peer code review. Instructions on creating a pull request.
4. After feature is complete `git flow feature finish <chosen_feature_name>` this will merge your branch to develop and delete your feature branch locally only. 
5. Now the final can be of your choosing, but you eventually need to merge to master and then deploy once tested. At work we would now create a release branch using `git flow release <release_number>` and repeat steps 2-4, replacing the final merge to master instead of develop.

*a hotfix is a pressing bug that will actually be merged to the master branch instead of the develop first. You will create these off master and follow the same steps 2-4.

Why:

So why do it this way? My answer is again to stay focused on feature at a time; it will also help when I actually get my app built out, I can work on multiple feature at a time if I get stuck or choose to work with another developer. I also will start using release cycles once my app hits 1.0 (i.e. has some sort of front end design).

If you are reading this and still learning rails in hopes to get a job doing it, I recommend trying this out, if it doesn't work for you, you can always delete the extra branches continue to push changes directly to master. If you do decide to do this, it would help you in the eventual interview since most companies use this or a similar technique in the development.

If you have questions or if something was unclear, please shoot me an email or leave a comment.