How Git Can Help You Develop a Software in a Team

This post is part of Proyek Perangkat Lunak (PPL) or Software Engineering Project Course. This post is aimed to explain the approach we use and the benefits we got by doing things related to software engineering in the project. #PPLpenuhmakna

Imagine you want to develop software with fellow developers. You gather up, dividing tasks, and code independently. After a few days, all of you have completed their tasks and decided to integrate the puzzle to build a big, fully working software. How do you integrate your code with the others?

One way is to send your piece of code to your friend and let him integrate your code with his own. Then, that friend sends the integrated code of you two to the other friend, and the process continues until all the codes are integrated into one big software. Sounds good, but how long will your friend integrate your code with his own? What if your friend can not continue his work because he needs your piece of code to complete his task? What if some bugs appear after the integration? Which integration creates the bugs? Can we do better teamwork than this one? Fortunately, we can. Git to the rescue!

Let’s understand Git with a scenario, building a website as my team does in Proyek Perangkat Lunak (PPL) #PPLPenuhMakna

• First thing first, you want to initialize your project so everyone in the team can contribute. Create the project folder and run git init.
• You want your friends to be able to see the project online. You decided to upload your git repository to a platform like GitHub, GitLab, or BitBucket. After creating the project in one of those platforms, you get a URL, something like https://gitlab.com/your-cool-name/your-cool-project.git. You then link that online repository to your local one. You use git remote add origin https://gitlab.com/your-cool-name/your-cool-project.git. The “origin” part is the name of your online repository and can be whatever you like, but it’s usually called “origin”.
• You decided to push your work to the “origin”. You run git push origin.
• Your friend is ready to work. He uses git clone https://gitlab.com/your-cool-name/your-cool-project.git. Since he clones the repository, he doesn’t need to set up “origin” manually.
• He wants to make a change, but at the same time, you’re still doing your job. He doesn’t want your changes to appear immediately in his code because it can break his code. He decides to make his branch. He runs git branch cool-feature. Because he wants to work on that branch, he switches branch right away by running git checkout cool-feature. Actually, creating a branch and then checkout can be simplified by git checkout -b <branch-name>.
• He edits index.html and wants to save the changes. He uses git add index.html to add the changes to index and then save the changes by running git commit -m "Cool HTML template".
• You’re working on your own cool feature, half away, but get excited by your friend’s commit. Because you don’t want your half changes to get committed, you decided to ignore your current changes but want to reapply it later. You use git stash, and checkout to your friend’s branch. After feeling satisfied with your friend’s work, you decided to go back to your branch and reapply your changes. You run git stash pop.
• Your friend continues his work, commit it, but realizes he gets it wrong in some places so he wants to undo his change. He runs git revert HEAD.
• You want to integrate your friend’s work with your code. In other words, you want to “merge” your friend’s branch with your branch. You run git merge cool-feature (your friend’s branch name).
• You get your friend works but find the history (by git log) quite unreadable. The next time you want to get your friend’s work, you decided to use git rebase cool-feature. This way, you “rebase” your branch based on your friend’s branch.
• You’re done with your feature! It’s time to upload your changes. You run git push origin.

That’s it!

As of the working flow (or git flow) itself, it depends on your team. In PPL, we use this flow:

For each sprint, we work on a PBI (product backlog item) branch which derived from staging. After getting our feature done, we can merge it into staging. If all PBI has merged into staging and the features look great, we can merge it into master which is the production branch. What if the product owner declines one of the PBI? Let’s create a coldfix branch and revert the PBI changes there, and merge again into staging. What if our code gets merged into master but later we find out a bug in that code? Let’s create a hotfix branch, fix the bug, and merge the hotfix right away into the master branch.

Let’s take a real example. Let’s say I want to build a feature (PBI) that shows donation schedules (jadwal donor in bahasa Indonesia). There’s a calendar and when we click on a specific date, it will show donation schedules for that particular date. We can break this feature into smaller parts, we call it task. One is to build a backend endpoint, let’s call it GET jadwal donor. So what I will do is creating the PBI branch from staging, for this case it’s PBI-1-lihat_jadwal_donor. It will contain all the changes needed to build the feature. To build subfeature, in this case the backend endpoint GET jadwal donor, let’s create the task branch from the PBI branch. So we create branch PBI-1/GET_jadwal_donor from PBI-1-lihat_jadwal_donor.

After creating the task branch, hours passed by coding the task and now it’s ready to be merged. Because it’s a task branch, it should be merged with PBI branch. Let’s create a merge request.

Your friends should review it and if they think it’s OK, your branch is ready to be merged.

Your friends reviewing your code.

One task is complete! Finish all the tasks required for the feature (PBI) and now you’re ready to merge PBI branch to staging (the master branch for developer). Let’s create a merge request.

After your PBI branch gets squashed and merged with staging, your feature is ready!

Sometimes, there are minor bugs here or there after the PBI branch gets merged. To incorporate this issue, we have a consensus to create a branch called “warmfix” from staging (see what we did there? ;) ). We then fix the minor bugs and after we are sure that there’s no other minor bug related to that PBI, we merge the warmfix branch. Note that this warmfix should be done as little as possible since it makes your repository gets harder to “coldfix” if your features (PBI) gets rejected.

After your feature and your friends feature get accepted during sprint review with the client, all of them can go into production by merging them into branch master. Then, you can go on with your life and build the next feature.

There are actually many things we can do with Git and tons of interesting Git flow out there. This is only one such but hopefully can give an overview of how Git can help you develop software in a team. Thanks for reading!