Git as A Fiddle!

Source: https://www.almtoolbox.com/blog/gitlab-pricing-is-changing-soon/

What is Git?
Based on its official website, Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. It is used to record the changes made in codes and to organize a group to work in a single repository project.

Git Manual
Let’s learn the commands for Git!

• git init: Command to initialize an empty Git repository or reinitialize an existing one.

$ cd Path/To/Code 
$ git init 

Here is an example, I am using the repository from our Markaz Pillar project. First, we go to our desired directory, perform git init and it will initialize a new git repository or reinitialize an existing one if git init has been performed before.

git init

• git pull: Command to update the local version of a repository from a remote repository.

$ git pull <branch_name> <remote_name>

In this example, I perform git pull origin master to retrieve updates from the remote repository.

git pull

• git push: Command to upload the local version of a repository to a remote repository.

$ git push origin <branch_name>

In this example, I pushed into branch pbi-23-landingpage.

git push

• git clone: Command to create a clone of an existing repository or copy of the target repository.

$ git clone <remote_URL>

In this example, I use a different new directory. First, we have to initialize a git repository, so we have to perform git init and then we can immediately perform git clone as seen below.

git clone

• git merge: Command to integrate changes from another branch.

$ git merge <branch_name>

In this example, the user is trying to merge into branch jeff/feature1.

Source: https://www.varonis.com/blog/git-branching/

• git rebase: Command to rewrite commits from one branch onto another branch.

$ git rebase <branch_name>
$ git rebase --abort

git rebase is used to rebase the current branch to another, while git rebase --abort is used to undo the rebase. Below is an illustration provided by Git.

Source: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

• git stash: Command to stash changes made to a working copy

$ git stash 
$ git stash list
$ git stash pop

With the git stashwe can use to save uncommitted changes for later usage, the command git stash list is used so that we can create multiple stashes and view them, the command git stash pop is used so that we can reapply the previously stashed changes

Source: https://www.geeksforgeeks.org/git-working-with-stash/

• git remote: The command to manage a set of tracked repositories

$ git remote add <remote_name> <remote_URL>
$ git remote -v

$ git remote remove <remote_name>

$ git remote set-url <remote_name> <new_url>

git remote add is to add a new repository, git remote -v is used to list all repositories, git remote remove is used to remove a repository and git remote set-url is used to change the URL of the remote repository.

git remote

• git checkout: Command to navigate between the branches created by the git branch

$ git checkout <branch_name>
$ git checkout -b <new_branch>

git checkout

• git branch: Command to list, create or delete branches

$ git branch <branch_name> 
$ git branch -a
$ git branch -d <branch_name>

Here is an example of some git branch commands. git branch <branch_name> is used to create a new branch, git branch -a is used to list all branches, and git branch -d <branch_name> is used to delete an existing branch. I used my former Advanced Programming course project for this one.

git branch

• git log: Command to show us commit history.

$ git log

git log

Let’s Make a Git Repository!
Make sure that you have made a repository at GitLab if you haven’t already.

First, we have to cd the path to our desired file and initialize an empty repository in our directory by using git init.

And then, we set the remote URL to the existing repository.

In this case, since I wish to retain the changes that have been done along with the history of the repository, I used git clone.

And we are done! Quite simple, isn’t it? You can now start using Git for your projects.

Agile Development in Gitlab
In Gitlab, several features help us with agile development. Here are those features:

• Issues and Issue Boards
  Contains the features from the point of view of the user.

Markazpillar Issues

We can assign issues into epics, milestones, iterations, and a person responsible for that task. We can also add labels, weight, and due dates.

Markazpillar Issues in Detail

We use issue boards to move around each issue to determine its status.

Issue Boards

• Epics
  Epic is quite similar to Issues, however, it is more general and has a larger scope than issues. We can assign issues into epics.

Markazpillar Epics

• Labels
  Labels help us organize and tag our work so we can track and find the work items we need to find.

• Milestones
  Milestones can be used as Agile sprints so that we can track all issues and merge requests related to a particular sprint. First, set a start date and name it as our sprint, then we just add issues into the milestone.

• Task Lists
  You can add task lists anywhere Markdown is supported. You must edit the Markdown manually by adding or removing an x in the brackets. Here is an example:

Source: https://docs.gitlab.com/ee/user/markdown.html#task-lists

And here is the result:

Source: https://docs.gitlab.com/ee/user/markdown.html#task-lists

• Burndown Charts
  Burndown charts show the number of issues throughout a milestone to see the progress of our project.

Source: https://docs.gitlab.com/ee/user/project/milestones/burndown_and_burnup_charts.html

That’s all for the Agile development features within Gitlab. With this knowledge, you too can start a software engineering project while applying the Agile development approach.

Experience in Using Gitlab with the Markazpillar Dev Team

In our Software Engineering Project, we are developing an application and to do that, we need to do our work individually. This is where Gitlab comes in handy. I had learned about Gitlab before, so I’m not exactly new to this and had already gotten used to the basic commands in Git.

To provide context, I’ll tell a little bit of our struggle throughout the creation of the Markazpillar application. One of the main issues that we experience is the conflicts between our branches. This would result in code losses, thus making some of the features unusable, this will affect the end product of our application. This is where our Holy Grail, git rebase comes in. Before fully utilizing the git rebase command, I used to do git pull instead, which automatically merges the branches together. However, in git rebase, we get to choose which code we get to keep. This is very crucial because we actually get to choose instead of having Git “assuming” things by itself. So this is a very important lesson learned from me.

In creating our branches, we decided to name it the PBI or the feature that we are currently working on. We also separate our staging and our production branches to prevent problems in production and avert poor performance for the end-user.

PBI as branches

There is this one feature that I find very useful, which is Merge Request. Since we separate the branches by each PBI and features/tasks, we ensure that the master branch is the one that has its pipelines pass, pretty much the version that we want for the end-user to see. So by creating merge requests, we can check on our teammates’ work and double-check on the features and the codes instead of immediately merging them into master, since it is better to fix it on the branch.

Merge request feature by Gitlab

We also utilize our Gitlab boards and issues very well, it helps us keep track of which features that we have finished or which ones do we have to do. It’s pretty much like a To-Do list in our project. I personally open up the Gitlab issues and boards first before diving into any programming to ensure the tasks that were assigned to me. This board really helps us with increasing the speed of our project. We can also put a label, which is very handy to know which issues are prioritized.

Markazpillar Gitlab Board

This might not be exactly Git-related, it’s more towards following the conventional commit naming. I think that this is very useful and very much overlooked because in my previous projects, I had always used ambiguous commit names and it makes it difficult for me to find the exact one commit that I need to find.

Ambiguous commit names

Now that I realize the scarcity of conventional commit names and brief descriptions. It is easier to navigate and look for the exact commits. Not to mention that since we are working on a big project with team members, we need to provide a clear explanation of the commits so that our teammates won’t get confused with our commits.

Using git’s conventional commit naming

I believe Git is an essential part of software development because it not only helps developers keep track of changes, but also measures the speed of each sprint and helps them collaborate on tasks concurrently, especially in this pandemic.