It has been a while since I learned Git. I must say it’s incredibly useful for my projects. (I was a fool for not having learned it earlier 🤓).
A few years ago I lost my precious hard drive with all my old projects (I should mention that they weren’t neither at any online repository nor on the Cloud). So now, I save absolutely all I do at Bitbucket or Github as a backup resource using git.
The Gitflow defines a very basic workflow created by different branches, each of which has a specific commitment.
There could be different approaches in your Gitflow. I’ll explain a brief description about the different branches:
MASTER, our masterpiece, “untouchable”. When a new release is finished, all the changes are merged once to this branch (one merge per tag, i.e v0.2.0), so you can see the list of commits for each version. All the code that appears in this branch is stable and, therefore, ready to launch.
DEVELOP, in this branch there must be a valid code, at least a compile code (without warnings or crashes at runtime). This branch is the parent branch for the new features and bugfixings in our project, i.e: your product owner (PO) wants a new feature within the app, so, the developer who has been assigned this new feature must create a new branch with a specific and “unique” name. If you’re using a project tracking software like JIRA, it’s recommended to create a branch’s name with the task’s code and two or three words (or a little description). You don’t only create a new branch for new features, also you create branches to fix bugs.
When a developer finishes his/her feature (or more broadly: a task), a Pull Request is created and it’s a good practice to make a Code Review, this means that, the whole team can see the coworker’s code before merging into Develop. Even more, the team has to approve their coworker’s code to merge into Develop, decline whether there’re typos or a bad pattern design, or… whatever.
Examples of branch’s names
- feature/MXZ-10_Login_Authentication
- Bugfixing/MXZ-24_Error_login
RELEASE, imagine that a new feature it’s finished or it’s time to release a new version of our app. This new version will be released towards QA’s department (there’re different environments to release a new version: DEVELOPMENT, TEST, PRODUCTION, etc) But in this example the context is the TEST environment, because is the first filter to other environments.
Note: we create this Release branch from develop with all the features up to date., whether a new feature is must be built, the developer creates a new Feature’s branch (from Develop), entirely isolated from the Release branch.
If QA’s department find bugs, these bugs could be fixed at the Release branch. If they’re not critical, these bugs must be fixed at the Develop branch, (creating bugfixing’s branches as feature’s branches). When the QA team have approved the Release version, the Release is considered to be finished, and is distributed to the next environment, for example Production. This means that a new tag is generated and all changes are merged to Master. Also, Gitflows inform us that all improvements (bugfixings) fixed at Release branch must be merged into Develop as well. So, all developers can keep on coding knowing that all the fixed bugs at Release branch won’t appear in the next release version anymore (false, because we can have regression 😁)
HOTFIX, if a bug is found in Master when the app is on Production, a new branch is created from Master. When the bug is fixed we can merge directly to Master (this is the unique case that developers can merge their code to Master) and also to Develop, we want to move all these changes into Develop too.