A (little) guide to Git

9 min readMar 21, 2021

This is written to fulfil individual review criteria for PPL Fasilkom UI 2021.

Git is a version control system (VCS) that can help the developer team to work collaboratively. Every developer involved can write code on their own. Later on, their code will be merged through Git. Besides that, developers can also manage source code changes from time to time easily. My team use Git (specifically Gitlab) as VCS to help us developing the project that we are working on.

Git Basic Commands

Git stores source code in a repository. There are two kinds of repositories, local repositories and remote repositories. Local repositories reside on each team members device. Meanwhile, remote repositories are hosted on the Internet which is accessible to all the team members. Here’s a very basic guide on how to use Git:

Setup

To initialize an empty repository, type this command in the terminal:

git init

If we want to continue to work from an existing repository, type this command in the terminal:

git clone <path_to_repository>

There are two options for the <path_to_repository> variable. It can be in SSH format or HTTPS format depends on how we want to clone it.

Remote name

A remote name is a “label” for a remote repository that is remembered by the local repository. This is the one that connects the local repository with the respective remote repositories. origin is the default name for the first remote and is usually where we push to if we don’t specify the remote name. We can have more than one remote in our local repository. If we clone a repository, it will automatically generate a default remote name for the remote repository. However, if we initialize an empty repository, we have to add the remote name by ourselves. Type this command to add a remote name for our repository:

git add remote <remote_name> <path_to_repository>

We can view the remote names that our local repository has by typing this command in the terminal:

 git remote -v

Our repository just has 1 remote

Making changes

There are 3 kinds of changes in Git, such as:

Untracked changes
Files that are only part of our local directory hence they are not part of Git. New files are usually part of untracked changes.
Unstaged changes
Changes that are part of Git but not marked for commit.
Staged changes
Changes that are part of Git and marked to be committed in the next commit.

To see which files are in untracked changes and which changes are in staged/unstaged changes, we can type git status command in the terminal.

Now, let’s say that we’ve already made some changes in our working directory, and we want to make them accessible in our remote repository.

To add modified changes to the staging area, use these commands:

git add <file_name> # add changes in particular filegit add . # add all unstaged changesgit add <directory> # add all changes in particular directory

To unstage changes, use this command:

git restore --staged <file_name> # unstage changes in particular filegit restore --staged . # unstage all changesgit restore --staged <directory> # unstage changes in particular directory

To commit our staged changes, use this command:

git commit -m <commit_message>

It will be nice to have a descriptive commit message so we can keep track of our code changes easier.
Descriptive commit message example: “Fix bugs in customer endpoint”
Non-descriptive commit message example: “I’m so tired of bugs omg :(”

Our staged changes have now become a part of Git history but it’s still not accessible in our remote repository. To do this, we have to type this final command: git push <remote_name> <branch_name>. Voila! Finally, we can see the changes in our remote repository!

Those are just the very basic Git commands that all developers are required to know. Now we will dive into more commands that are commonly used in a Git Flow, especially for PPL 2021.

Git Flow in PPL 2021 (+possible needed commands)

Form of collaboration in the context of using Git version control using a pattern known as Git Flow. It is designed to make tracking the work of each team member a lot easier, make master branch neater to facilitate deployment, and manage the release version better.

Git Flow that is implemented in PPL 2021 can be illustrated in the following diagram:

A branch represents an independent line of development. When working on a new feature, it’s better to make its own branch so our goal can be focused on that feature alone. When it’s done, we can integrate that new feature by merging it with the larger branch.

Here are some branches that are used in Git Flow PPL 2021:

Master
The main branch that stores ready-to-deploy source code into production environment. This is a protected branch so only git masters (teaching assistants) have access to this branch. The source code that is stored here is ready to be used by the user. It only accepts changes through merge request from staging when sprint review. Git master can only merge upon the approval of the product owner/lecturer.
Staging
A branching from master branch. This is the main branch of the developing process. This branch will store every developer’s source code in one place. It will mainly be used for sprint review.
PBI[1..n]
A branching from staging branch. This branch will store source code implementation of a product backlog item that’s taken in a sprint. TDD is obliged to be implemented here. It can only be merged to staging branch through merge request approval from a minimum of 2 people with code reviews.
Hotfix
A branching from master branch that is created if an error occurs in master. This branch will contain bug fixing code. After the bug is fixed, it will be merged over to the master branch.
Coldfix
A branch that is created to do the rollback, which is deleting all changes from a PBI branch. It could be happened if the Product Owner (PO) refuse to release the PBI that we‘ve implemented.

Commands/things that probably needed:

Branching

To list all the branches in the repository, we can use this command:

git branch --list

The one that’s highlighted is the current branch we are on.

git checkout <destination_branch>

To create a new branch, execute:

git branch <new_branch>

To create and move to a new branch, execute:

git checkout -b <new_branch>

For example, we want to create the PBI branch from the staging branch. We can do this:

git checkout staging
git checkout -b PBI-n-description

To delete a local branch, execute:

git branch -d <branch>

If git refuses to delete our branch because we still have unmerged changes or anything, we can force the branch deletion using:

git branch -D <branch>

To delete a remote branch, execute:

git push origin --delete <branch>

Updating & merging changes

If we want to fetch a remote branch that doesn’t exist in our local, execute:

git fetch <remote_name>

This command will download changes from the remote branch but leaving our local branch unchanged.

To update our local branch with the fetched data, execute:

git merge <remote_name>/<branch_name>

This branch is not in our local yet, it’s taken from the remote branch

Merging preserves history in our repository.

If we want to update our existing local branch, we can use the fetch + merge command. It turns out that they can be combined into one command, which is:

git pull <remote_name> <branch_name>

We can also integrate changes with this command:

git checkout <branch_1>
git rebase <branch_2>

Unlike merge , rebase will move the entire source branch to begin on the tip of the destination branch. Rebase will modify history in our repository.

Details:

Suppose that we have this current state in our repository:

Source: https://code.tutsplus.com/tutorials/rewriting-history-with-git-rebase--cms-23191

If we do this,

git checkout feature
git merge master

This is what happens:

On the other hand, if we do this,

git checkout feature
git rebase master

This is what happens:

Commit history

To see commit history, execute:

git log

Undoing changes

We can use the following commands to delete changes from a branch (rollback).

For the coldfix branch in Git Flow PPL 2021, it is recommended to use the revert command.

git revert <commit_hash>

Example:

If we want to roll back to the changes before the latest changes:

git revert HEAD

It’s safer to use revert because revert undoes things by introducing a new commit so it won’t modify the commit history.

The other way to undo something is using the reset command:

git reset --soft <commit_hash>: uncommit changes, changes are left staged at index
git reset --mixed <commit_hash> (default): uncommit + unstage changes, changes are left in the working tree
git reset --hard <commit_hash>: uncommit + unstage + delete changes, nothing left

git reset will change the commit history, unlike git revert.

Saving changes

If we are on a branch that has changes that haven’t been committed (staged/unstaged/untracked) but we have to work on something on another branch, git stash will be useful to save them for later use.

To save the changes, execute:

git stash

As we can see, there are still staged changes in this branch

And this is what happens when we stash them, there are no changes seen in `git status` because git already saved them for later use

To reapply the previous changes, execute:

git stash apply# orgit stash pop

git stash apply will preserve the stash after applying it, however, git stash pop will also remove the changes from the stash.

To display the list of the stash that’s saved, execute:

git stash list

git stash apply + git stash listusage example:

The stash is still there

git stash pop + git stash listusage example:

Implementing Git Flow in PPL

In my team PPL project, we implement Git Flow as a branching model according to the given guideline.

As I mentioned earlier, merging PBI to staging is only possible upon the approval of a minimum of 2 (two) other team members by reviewing the code. Here is an example of my merge request: