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 projectinto your local repository.
cd into the repository
check the branch you are currently on
Create a newfeature branch
Start working on your feature and when you are done,add,commit andpushto the feature branch
Go 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 adevelopmentbranch
Check 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 thedevelopmentbranch, create a pull request from it and merge todevelopmentbranch.
When 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.