Working with Git

Using Git from a perspective of a young developer that may not fully understand its full potential

Git is a really useful tool when working on a team. Members can work on their own, and in a certain time those works is combined into one. In this article, I will tell you the commands that I usually use, and touch a bit about Git flow, the workflow used in our project.

Commands

To start off, pick a directory in your computer. There are 2 ways to start: git init and git clone.

• git init is used when you start without using any existing repository.
• git clone is used when you start with an existing repository. This is the technique that I normally use.

After that, you can start working on your project. When you’re finished with your current work, add the changed files to staging using git add.

• git add <file_directory> to add a file.
• git add . when you want to add all changed files.

You can see which files has been added and which files hasn’t by using git status.

git status on my current directory (no changes)

git status when there are changes

Using git status, we can also see what branch we are on, and review what files we have added before committing. If we feel like we’ve made a mistake, we can discard changes using git restore.

(Tip: if we want to add/restore all files in a certain folder, you can use folder_name/*)

If we’re satisfied with our changes, we can commit those changes using git commit. Usually, we’re prompted to add a commit message with your default text editor. To skip this part, we can write our message with the command with git commit -m “[MESSAGE]”

After committing, we can push our changes to our remote repository using git push origin <branch-name>.

Working on a branch

If you’re working on with branches, it’s advised to check what branch you’re currently on before you start to work. You can do this using git branch. The branch you’re currently on will be highlighted with an asterisk and green text.

git branch

If you’re not on a branch you want to work on, you can change branches using git checkout <branch-name>. If the branch you want to work on doesn’t currently exist, you can make a new one using 2 ways:

• git branch <branch-name> to make a new branch without moving into it, then you can use git checkout to move there.
• git checkout -b <branch-name> to make a new branch and move immediately into it.

Continuing your work

At times, you will need to pull the current changes in your remote repository as your team members have also pushed their changes. We can update our local repository using git pull origin <branch-name>.

While I don’t think it’s going to be used in our project, you can merge two different branches using git merge. Our project doesn’t use this as there are some reasons why:

• We’ve separated our project into parts (PBIs), so for now we don’t think we will need to merge branches (at least between PBIs)
• When we merge branches, we usually merge it into the staging branch or master branch. Merging to those branch requires merge requests, and it will need approval from PO before it is merged. Merge request are usually made in our Gitlab.

I’ve made a mistake

When I’ve made a mistake, I usually use git stash to stash all changes I’ve made. Normally git stash is used to stash current works that are not yet finished, but I just use it to discard the changes I’ve made (this was before I somehow just discovered git restore).

There’s also git reset, which will reset all changes in your current commit, or git revert, which will push a revert commit containing inverted changes from the newest commit to the head of the branch. I rarely use these two commands though, as git reset can be dangerous if done wrong and git revert means admitting you made a mistake.

If you want to see past commits, you can use git log.

git log

Using this will show the hash for each commits, and these hashes can be used when you want to use git reset.

Gitflow

The workflow we are using for our project is gitflow. Gitflow makes it easier to track changes in master, and parts of the project is separated and put into different branches. For example, branch PBI1 is working on feature X and its related components, while PBI2 is working on authentication.

The main branch is master, and master has a subbranch called staging. staging has various subbranches called PBI-#, where the features of the project is worked on. After working on the PBIs, these features are merged into staging, where it will be reviewed by the PO before it can be merged into master.

While gitflow has its pros and cons, I don’t think I can give my opinions on this workflow as this project is still very early in development. Maybe some other time.

That is all that I can tell you in this article for now, I hope it can give you a good information about using Git. Thank you for reading!

(note: this article was made when our Gitlab repository is down, thus the lack of screenshots.)

References:

Git Handbook

Git Revert | Atlassian Git Tutorial

Gitflow Workflow | Atlassian Git Tutorial