Working in Team at Development using Git

8 min readMar 21, 2021

This article was created for the purpose of individual review assignment of PPL 2021

Most, if not all developers are already familiar with Git. Due to how popular it is, some people might just be using it without really bothering to know about the advantages and benefits of it. In this article, I’m going to talk about some benefits of using Git, a few basic implementations of it, and some examples of the workflow on Git.

What is Git?

https://git-scm.com/images/logos/2color-lightbg@2x.png

Git is a version control version, which is free and also open-sourced, created to handle the development of projects. Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. You can access all of the records anytime, whether to revert changes of a file to a previous state or to recover lost files.

Some benefits of using Git

Feature Branch Workflow

When working with other people, there tends to be some problem, like you accidentally screwing up the works of someone else on the projects. This could be avoided while using Git since feature branches provide an isolated environment for every change to your codebase. You could create a new branch to work on a new feature without worrying to accidentally ruin the main project since the changes on the new branch won’t affect the master branch where the main project is allocated.

2. Distributed Development

With Git, every person working on a project could get their own local repository, complete with all of the commits done on the repository it pulls from. You could do a lot of things on it, like creating a commit and inspecting the previous commit on the repository, even without using the internet. When people are done with their work, they could push the repository at any time to the main repository without having to wait for other people to complete their own task, making the workflow progress much faster. Also if you somehow screw up a lot in your repository till the point of no return, you could just delete the repository and create a new one by pulling it from the original repository.

3. Pull Requests

Pull request is a way to ask the other to merge your branch to their branch. You could use this for a lot of things, for example when you need the help of others to review your code before merging it to the other branch. With pull requests, you could also start a discussion regarding your work before integrating it into the main repository. This way you could make sure of the quality of your code by having it reviewed by others.

Risks of not using Git

I have never tried to work on a team project without using Git, but here are a few risks that I could imagine if you decided not to use Git for your group project.

Hard to integrate your works with others

Imagine when you’re done with your works and want to integrate them with the main project, but your friend already integrated his/her works after the last time you pull from the main project. You need to review manually all of the changes that have been made to make sure you didn’t accidentally change someone else's works. With Git, you just need to pull from the main branch before you merge your branch with it, and it will automatically tell you if there has been a change that got overwritten by your works, and tells you to fix it personally before you can proceed.

2. Couldn’t recover easily if you make a mistake

There are a lot of times that you make a mistake when working on a project, but sometimes you didn’t realize it until a later time, and it’s too late to change it back since you already saved all the changes. With Git, you could store all of the histories of changes you made in the project, and revert all of the mistakes you’ve made with the git revert command.

Few basic commands of git

Here are a few examples of basic commands of GIT that you could use on the command line.

Git pull

Used when you want to fetch and integrate another repository to your local branch. Basically, it runs git fetch to the target branch, before calling git merge to merge the target branch head to the current branch. Usage example: “git pull origin <branch_name>”: will pull target branch to the current branch.

2. Git push

Used when you want to update remote repository using your local repository. It simply pushes the current local repository to the remote repository, mostly the same name as the local one. Usage example: “git push origin <branch_name>”: will push the current branch to the target branch.

3. Git clone

Used when you want to clone an existing remote repository into a new directory. Usage example: “git clone <repository_link>”: will clone the branch in the link to the current new directory.

4. Git checkout

Used when you want to change the current local branch to the target local branch. You could also use this command to create a new local branch while simultaneously copying the current branch to the new one using “-b” options. Usage example: “git checkout <branch_name>”: will switch branch from the current branch to target branch.

5. Git merge

Used when you want to integrate another branch with the current branch. To put it simply, it applies all of the commits from another branch to the current branch. Sometimes you need to resolve some conflict, which happens because there are a few differences between the two branches before you could merge them. Usage example: “git merge <branch_name>”: will merge the target branch to the current branch.

6. Git branch

Used when you want to list, create, or delete branches, depends on the arguments used. Usage example: “git branch”: will list all of the local branches in your computer, while also tell the info about the current working branch.

Implementation example of git commands

git clone and git branch

cloning a remote repository to local and checking the branch

With “git clone https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2021/CC/jagasatwa.git”, I'm cloning my project remote repository to local, and then I'm checking the current branch with “git branch”.

git checkout and git pull

With “git checkout PBI-14-melihat_profil_shelter”, I’m switching the current local branch to PBI-14-melihat_profil_shelter branch before pulling from the staging branch with “git pull origin staging”. This action will make my PBI-14-melihat_profil_shelter branch up to date from all the changes that have been made in the staging branch.

pulling staging branch from PBI-14-melihat_profil_shelter branch

git add, git commit, and git push

saving all of the changes in the project before pushing it to PBI-14-melihat_profil_shelter branch

With “git add .”, I'm saving all of the changes to all files in my project, before committing it using “git commit -m “[CHORE] menghapus comment pada views.py profilepage”. Then, I push the commit to the remote repository of the PBI-14-melihat_profil_shelter branch using “git push origin PBI-14-melihat_profil_shelter” command.

Difference between Git Merge and Git Rebase

You could use both Git Merge and Git Rebase command to integrates your branch with another branch, but there are a few differences between the two.

Git merge keeps all of the commit histories of the source branch, while Git rebase makes all of the commits from the source branch into a single commit, and integrates it to the target branch.
Git merge only integrates the source branch with the target branch while keeping the source branch intact without any change. Meanwhile, in Git rebase, not only the target branch got changed, but the source branch got moved to the last commit of the target branch. This result in the different project history, in which Git merge got some branching in the history with its own commit and target branch commit, while Git rebase got cleaner history without any branching. Here’s the illustration below.

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

Example of workflow with Git

https://scele.cs.ui.ac.id/pluginfile.php/99036/mod_resource/content/1/Panduan%20Git%20PPL%202021.pdf

Git flow is a form of collaboration in the context of the usage of Git. When using Git flow, the work of every member of the project could be easily tracked, because most of the works of the member are separated by individual branches created. Here are some brief explanations of Git flow when I worked on my project.

There are a few branches that I already implemented in my workflow, specifically:

Master branch: The main branch of the project. stores the source code of the project that’s ready for deployment.
Staging branch: The main branch that was used for development. Store all of the source code from all the branches that stored individual work of each member. All of the integrated code will be tested and reviewed before it’s ready to be pushed to the master branch.
PBI branch: Used for the implementation of specific features of the project. The features will be developed with TDD and will be pushed to the staging branch when it’s finished.
Hotfix: Used for fixing bugs and errors on the master branch. When the issues are fixed, this branch will be merged back to the master branch.
Coldfix: Used to erase all the changes on the staging branch from all the PBI branches. Happened when the client rejected the features in one or all of the features implemented from the PBI branch.

After the master branch and the staging branch were initialized, the first thing we do was to set up the working environment for the project on the staging branch. When it’s done, Then we finally create the PBI branches based on the features divided among the members.

creating a new PBI branch from the staging branch

Since there is no working product yet ready to be deployed, we emptied the master branch and continue to develop the project in each PBI branch. After the implementation of a feature is complete and working, then I finally can merge it to the staging branch to integrate it with the main project. But before requesting to merge with the staging branch, we need to pull the staging branch to the PBI branch first to resolve all the conflict since there might be another member that already merged their own PBI branch.

pulling the staging branch to the PBI branch

After all of the PBI branches already merged to the staging branch, we need to review and test the code to ensure that all of the features are integrated and working properly before pushing it to the master branch to be deployed as a working product.

That’s all from me. Thanks for reading this article!

Reference: