Going with the Gitflow

This article was written as an Part A Individual Review assignment of PPL CSUI 2021

https://www.toptal.com/gitflow/enhanced-git-flow-explained

What is a ‘gitflow’?

Gitflow is a process of managing changes in Git during development. The general idea behind it is to have several Branches that each serves a specific function.

This article is written in consideration of my personal experience with PPL 2021’s Gitflow, which sees changes to the contemporary Gitflow with its own personal twists and turns.

What are those branches?

Gitflow has two “Master” branches. Master and Develop (in PPL 2021, we call Develop ‘Staging’) . Develop serves as the master branch during development for integrating features, while the titular Master branch stores the official release history, the actual product, and in several cases, is a protected branch.

This is how Staging looks like in our project

There’s also the Feature branches. It serves as the branch where the developer develops a specific feature from the requirements. It is created off the latest Develop branch.

In PPL 2021, we call these branches PBI branches, in accordance to the PBI we’re tasked with, with this naming convention:

The PBI branches in our project, the naming convention is “PBI-[PBI #]-[PBI Name]”

When a Develop branch has amassed enough features, a Release branch may be created off it. Having a separate branch dedicated to polish the product from the branches used to develop features allow the team to allocate their manpower better and makes management easier. Interestingly in PPL 2021, we doesn’t utilize this branch.

On PPL 2021, on the off-chance our Product Owner rejects some or even all of our PBI during the Sprint Review, we create a Coldfix branch, where we reverts the changes that are rejected and be merged back into the Staging branch. The visualization of Coldfix is as follows:

The sequence of coldfix

When a bug or error appears on the release version (Master branch), a Hotfix branch is created off the Master branch, and is used by the developers to fix those bugs and errors. Once it’s done, it is merged back to Master branch.

The tl;dr for PPL 2021 Gitflow

  • Master branch is for release
  • Staging branch acting as the master branch during development
  • PBI branch is for developing PBIs
  • Coldfix branch to revert and rollback changes from PBI branches during development
  • Hotfix branch to fix bugs and errors from the release version

The Gitflow manual, PPL 2021 style

The Beginning

First of all, you need to initialize git on your local directory, and then adding the URL to your remote repository.

# Initializing
git init
# Adding remote
git remote add origin https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2021/example-project/example-backend.git

Next, you need to create the Staging branch and Push it to the remote repository.

# Creating Staging (-b creates a new branch)
git branch -b Staging
# Pushing the Staging branch to the remote repository
git push origin Staging

Branching (for PBI, Coldfix, and Hotfix branches)

To create a branch off an already existing branch, you do this:

git checkout -b <the new branch> <the target branch># So for example, if I want to create a branch 'PBI-2-Quiz' off the # 'Staging' branch it goes like this:
git checkout -b PBI-2-Quiz Staging

Adding and Removing files

Before committing changes, you need to add files that is being changed first. It goes like this:

# Adding all files to commit
git add *
# Adding specific files to commit
git add <filename>
# Removing files
git rm <filename>

Commit

In PPL 2021 we agreed to make a cohesive commit, where each commit is supposed to only contains files from a specific workload/feature, to make it easier to track and revert the changes.

The commit sequence itself adheres to TDD principle:

  1. Commit that contains the skeleton for class and functions
  2. Commit that contains the test for those skeletons, its commit name tagged with [RED]
  3. Commit that contains implementation that passes the test above, its commit name tagged with [GREEN]
  4. For commits that changes/fixes the previous implementations, use a commit name tagged with [REFACTOR]
  5. For commits wholly unrelated to functionality, use [CHORES] tag
# Creating commit 
git commit -m <your-msg>
Our team’s commit history

Pushing Changes

To push changes that you’ve committed, you do this:

# Pushing changes
git push <remote-name> <branch-name>
# In this case, the remote name is 'origin' and the branch name is
# 'PBI-4-Example'
git push origin PBI-4-Example

Merging commits into Staging

Once you’ve pushed your changes to your PBI branch, and it passes the pipeline, you may want to merge it into Staging. To do this you create a merge request. This merge request has to be reviewed and approved by two of your teammates.

Reverting Changes (from a merge)

This is mostly prominent on Coldfix branch, for example, if you have a merge that was made by two commit, ‘A’ and ‘B’ and you want to remove the commit from A:

# The revert command
git revert <parent-number> <commit-id>
# Assuming A's Parent id is 1, and the merge id is 86ab28a1
git revert 1 86ab28a1
# The end result is the merge without A's commit

Why would you use Gitflow?

If you’ve read this far down, you may ask ‘why would I ?’. The usage of development workflow itself depends on the kind of projects you’re working on.

Gitflow is ideal for projects that have a scheduled release cycle with multiple versions in its production, such as PPL 2021 itself.

GitHub Flow is best suited for projects that only has single version in its production.

GitLab Flow is best suited for projects that only has single version in its production, but requires an issue tracker (may be due to the project’s complexity)

Even when you settles with Gitflow, you don’t have to follow its rules to the t. You can make changes that suits your project and development cycle, just like what PPL 2021 did with its Gitflow.

That is all, folks. Have fun coding!

References:

A standard computer scientist.