Version control has become an important part of the software development process. Version control helps record changes to a project over time so you can recall specific versions later. I will be talking about GitHub.
When I started out as a developer, I started using GitHub because everyone said it is necessary for developers to have their code online. With that in mind, I viewed it as a place to store all my projects in case my system crashes, I would be able to download them back.
Funny right?
Later, I realized GitHub was more than just that, it is a place where I could view all the progress I have made at each step of building my project or software. It also happens to be a place where everyone around the world can contribute to projects with different ideas.
Around Mid-year, I started at Microverse, I was introduced to GitHub Flow. GitHub Flow encourages you to create feature-branches for each feature of your software. When you believe your software or project is ready to be viewed or used, you create a pull request and merge to the master branch.
Cool right?
clone the projectcdcheck the branch you are currently on
Create a new
feature branchStart working on your feature and when you are done,
addcommitpushGo to your remote repository on GitHub and create a pull request and merge when you believe the feature is completed
This way you get to view all the features you created and what you added at each phase. As I progressed, I realized the master branch was mainly for production and the moment you merge a pull request you are saying that feature is ready to be used or viewed by everyone.
It was then I came to the knowledge that GitHub flow works perfectly for small projects, but what if I have a project with more than one important feature and I use GitHub flow, I am indirectly saying all features that are merged to the master branch are ready for production but if we think about it, are they?
Releasing one feature for a project with many features doesn't make sense and that's where Git Flow comes in. It is very similar to GitHub flow but introduces a better way to work with version control.
In Git Flow, we create a development branch and then make the development branch the default branch until we are ready for production. This way, all the feature-branches are created from the development branch and merged into the development branch when completed.
Makes sense right? Now, I only get to merge to the master branch when I believe my software is ready for production with all features added.
After cloning your repository, Create a
developmentCheck to see what branch you are currently working on
Try to add a file, maybe an HTML file so you can update your remote repository with the development branch.
Go to your remote repository on GitHub , go to settings, click on branches and make development the default branch
Now, you can create feature-branches from the
developmentdevelopmentWhen all your features are ready, follow the same steps above, make master default again, create a pull request from development to master and merge for production.
I know it has been a long read, but I trust by now we should know when to use GitHub flow or Git Flow.
Thank you for reading.