A Git Guideline for You

Published in

Inside PPL B7

8 min readMar 30, 2020

Computer Science Students always develop a program, we will produce source code. I use ‘we’ because developers often do not work alone, there will be two or more developers working on the same source code, so we need to collaborate our project using a Version Control System.

What is Version Control System?

It’s a software tool that helps developers record changes to files by keeping a track of modifications done to the code. A developer can easily look up the current and previous versions of their codes. This system allows the developer to go back to the older version of their codes. By using VCS, any changes to the software such as adding files or changing the contents can be monitored which parts are changed and who changes. So, the software will be more transparent and measurable.

How about Git?

Git, one of the VCS, is a decentralized version control system who has benefits like repository syncing, offline working, cheap local branching, comfortable staging area, can handle a big project. The difference from other VS is the way thinks about its data. When the user commits some work, Git will take a picture of how the whole files look and store the reference to that snapshots of a miniature filesystem. Git focuses on the file content itself, thus it would be able to determine exactly what the storage and version history of the file tree should be. As Git is distributed, the code in the remote repository is also present in all developers’ computers in the form of a local repository.

I’ve personally have used Git many times, I learned about Git from the 3rd term. Git has become a part of all of the projects that I’m working on. From my experience, using Git can be very hard and to be honest, I still have a trauma using Git because of its conflicts. But now, I can’t imagine have a collaboration development without Git :(

How to use Git?

First of all, you need to download Git which can be found here. Follow the installer and we can get started.

Check your git version by open a terminal and run the command below

$ git — version

Configure your git username and email by the command below

$ git config –global user.name “<your-username>”$ git config –global user.email “<your-email>”

You can try to view your git configuration by the command below

$ git config – list

This will return an output of your user.name and user.email

How to start a new repository?

A repository is similar to a project folder that all changes inside the folder could be tracked by Git. You need to have an account in a Git repository hosting service such as GitLab or Github in order to create your remote repository. For this time, I’ll be explaining by using GitLab due to the usage of GitLab for the first time.

First, make a new project on your GitLab account.

Step 1: Click on the ‘New Project’ on the GitLab’s navbar

Step 2: Insert your project name and set the visibility

Step 3: Click ‘Create project’ button
Step 4: Copy the link of your project by click ‘Clone’ dropdown button and copy the link

You need to connect your local and Git repository in your work folder by the following command:

$ git init

to initialize a git repository inside your local working folder

There will be a .git folder that enables to make a git folder in our local to become a git repository

$ git remote add origin <your-git-repository-url>

telling our folder to be connected and tracked into a repository, more like backup remotely

$ git status

to check what is going on in your repository

How to add local files to the remote repository?

There is already a file or changed file in your working folder and you would like to store the files to the remote repository. You can use the following command:

$ git status

to see unstaged or staged files

$ git add

Adds any changes in any file in your working directory that stage them to the staging area for commit,

$ git add <file-name> // add specific file
$ git add .        // add all changed files in the working directory
$ git add -A       // add all files in the working directory

$ git commit -m "<your-commit-message>"

To record and name your changes, commit message will be used on the timeline of git changes of your repository

$ git push origin <branch-name>

To push your local changes to a remote repository. If your work is behind the remote head, Git will ask you to pull first

You can clone the repository on another machine

$ git clone <your-git-repository-url>

To get an online repository into your local directory and will also create remote-tracking branches. Remote-tracking will let Git know how local and remote branches related. We don’t have to specify the branch when we are trying to pull and push if we have those remote.

How to get files from a remote repository?

If your remote repository has been updated by a fellow project member and you would like to update your local repository, you must have this following command

$ git pull origin <branch-name>

It usually was done before pushing to the remote repository to ensure possible conflicts are resolved, this command was forgotten by me if I want to push some changes. If the branch that you tried to pull diverges from a remote repository, Git will try to merge the changes automatically. But, if there are conflicts, Git will let the developer fix any conflicts then commit the changes.

The difference between git clone is this command is for you who already had a current version of the project in Gitlab.

How to manage branches in Git?

Git has a structure that like a tree, we have a main branch called ‘master’ who represents the trunk of a tree. The tree also has multiple branches that can modify, make changes, without affecting the master branch. If we want to apply our changes to our branch into master, we can merge it.

Create a branch and switch to the new branch by run this command

$ git checkout -b <branch-name>

Confirm branch that will give an output of all your branches, a * will appear next to the currently active branch.

$ git branch

If you have completed your branch and want to update your master with the branch, you could do it on your command prompt in branch master

$ git merge <branch>

Or you can simply use the GitLab feature, Merge Request, by clicking the button ‘Create merge request’ and fill the description, assign a person to review your changes, and click the ‘Submit merge request’. If the assignees had reviewed your changes, they can Merge your request by clicking the green ‘Merge’ button.

After you’ve done with a branch and want to switch to another branch, you could use this command

$ git checkout <branch-name>

Advanced Git manual you need to know!

$ git rebase <branch>

Used to update the current branch when the master branch got an update which you also want in your code. It will make your commits look linear and integrate upstream changes into your local repository.

$ git revert

Used to record some new commits to reverse the effect of some earlier commits. We use it when an unexpected error happens and triggers a pipeline failure.

$ git stash

To save any changes you have made since your last commit. If you want to move branches, but you don’t want to commit yet you could use this command.

Git on my Software Engineering Project

Master

The main branch that stores code that is ready for deployment into the production environment.

Staging

Branch associated with the development process. This will store the code of the results of the work of each developer collected in one branch. The application that will be used during the sprint review is from this branch

PBI[1..n]

Branch for the implementation of a Product Backlog Item taken on a Sprint. Later, there will be several branches of PBI named according to the name of the PBI being developed

Hotfix

Branching of the master branch is created if there are bugs or errors in the master branch. This branch is used as a place to fix the bug fixing that occurs at the master branch. After the bug is fixed and ready to be delivered, this branch will be returned to the master branch

Coldfix

Branch created to rollback, delete all changes from all PBI branches. This can happen if when doing a Sprint Review, the product owner rejects one or all of the PBI that have been implemented for release.

Initialize the master and staging branch in the repository, which done by Git master
Initialize the PBI branch for implementation by each developer based on the taken task
Using TDD on implementation
Merge PBI branch to staging branch when it’s completed. We make another branch on staging for every sprint, so we merge the PBI branch to the sprint branch first after all of the developers review the branch of each member. After the sprint branch is completed of all PBI of the sprint, then one of us merge the sprint branch to the staging branch for the Sprint Review.
Adjust the staging branch to be merged with the branch master

Happy do git!