Git Flow Hands-On — Best Practices

7 min readAug 1, 2022

Thank you for visiting my Git Best practices article. So today we’re going to be talking about it Git flow and how to create pull requests and review them within Bitbucket. The scope of this article isn’t going to be covering how to install Git or set it up, or bitbucket. There’s lots of tutorials out there on the internet very good, and how to do that.

We’re just simply going to be covering how to use Git flow and bitbucket in a best practice manner, so that you’re able to fully manage your code in a way that one you don’t end up introducing unnecessary bugs, or stepping on the toes of other developers if you have other people working on your project. It also means that you have a lot more flexibility on your codebase if you’re working on it by yourself. So I’d like to start off by talking about this tutorial from the Atlassian website.

Now Master is always going to contain your most stable code, and it should always be up to date with what is currently live in production. The reason why we don’t commit to master is because we don’t want to introduce any unnecessary bugs or step on the toes of anybody. And also, if anything were to happen in production and you need to release a quick fix for it. If you’ve then been committing to master you don’t have the same version of code anymore. That’s live in production. So if you then implement the fix on here, and this is a few revisions after production, you could and you introduce a new code again and you introduce some risks. So everything should be done on the develop branch. This becomes your default branch. And everything’s going to be worked on here. Until you decide to do a release at that point. It can get merged back into master.

Master and Develop Branches

So to begin with, I’m just going to create a new repository in bitbucket, or Git. Yes, make it public. So first, I’m just going to clone this down. I’m going to get clone and then my URL. And I’m going to change in some directory. If you’re not sure which branch you’re on, you can either run git status or git branch. Once we push something up, you’ll be able to see which branch you’re on I’ve typed in the command git branch. So with that in mind, let’s just initialize this further.

Commit it and then let’s push that to GitHub. So there we go. This is now fully initialized.

Now we need to also push up this branch. So push origin developer

I’m going to create my feature branch. Now I need to give it a really meaningful name. One of the hardest things in programming is naming things always wants to ensure that the name that we give things whether variables, classes, methods, functions, branches, that that explicitly convey the meaning of what we’re trying to do here. As you can see here feature branch gets a branch off of development. So we’re developing our main branch we’re going to develop, develop, we’re going to commit on this feature branch. Now the feature branch is typically going to be unstable because you’re you’re working on a feature and you’re working through that you don’t you haven’t got everything implemented as you’re working along. So I work on a feature branch. That means that other developers can then branch off of develop and do the work they need to do and then merge that back in without having any conflict between the stuff that you’re working on. This also works great if you’re working on a project individually, because you may start working on a feature and you find that actually, something more important needs to be done and you can go back to the verb and start a new feature branch work on that. Get that merge back in, get that released. Then merge back into master and then continue working on your original feature branch before. So let’s have a look at my feature branch here.

I made some modifications to the test and readme file. I’m gonna push this up to origin feature.

We want to create a pull request. So this is a request to saying to you can share vote of the developers and say, Hey, guys, I’ve just been working on this branch. This is the code that I’ve been doing. Can you have a look at it for me is everything okay? And if it is, let me know and I’ll go ahead and merge that in. Now again, if you’re doing this you’re working on the project individually, this is still a great practice to follow. Because within here we can see the commits that we’ve made, and the files that have changed so I can review all the changes within here, so I can double check the stuff that I’ve done is correct.

Merge the feature to develop and delete this feature branch once merge is completed

This is to avoid confusions on too many branches

Okay, so at this point, let’s have a look at the next step within Git flow. We have release branches. This release branch is forked as part of develop branch and hardened for the next release for production deployment

Update the release notes for next planned release

Add and commit the hardened changes for the release

Git push to release branch

Create pull requests to merge into master and develop

Finally, we have hotfix branches where hot fixes are for if there’s a bug that’s been discovered in production, you need to get a quick fix out for that. You know, since you did that release, here, that develop may have continued to have more commits added to it. So we don’t want to be doing a hotfix of develop because we’re going to be introducing changes that may not be stable yet, or you know, there might not be a place where we really want to be introducing new code. So we want to do a hotfix based off of master. So if I now check out master again, and we’re going to pull down those changes. As you can see that readme changes that again, I didn’t have those changes locally, so I need to make sure I pull those down.

First. Now we’re going to create a hotfix -