Familiarize Yourself with Git

9 min readMar 20, 2021

This article is written as an Individual Review Assignment for PPL CSUI 2021

Legend :

<> = optional to use
[] = mandatory, content depend on your own content

To create a whole project alone is not something easy to do, however to create a whole project with a group does not mean it is going to be easier. Each people have their own way to work, sometimes modifying each other work without permission. This kind of event obviously will spark the fire in the development group. However, this kind of thing can be prevented by using Git.

Found by Linus Torvalds at 2005, Git is a Version Control System (VCS) that was designed to record changes to a file(s). Git will make maintaining code become easier, as it is possible to see changes or even previous work that was already modified. By using Git, having a project in group will become easier. Comparing code line by line manually will be no more, and to see the difference will become lot easier.

In this article, I would like to explain basics about Git. Some of the demonstration will be done by using GitLab. To be able to implement things using Git, make sure you have installed it on your computer, you can download Git from here.

1. Creating a new Repository

The very first step to create a repository is to create a new Repository at GitLab.

Right after creating a new repository, make a folder in you local machine. Then the following command need to be run in the folder directory using the computer terminal.

git init

After you run this command, the folder will become the repository. Every changes made in the folder will be recorded by Git.

2. Adding Remote

git remote add [remote-name] [repository-url]

By adding new remote, it is possible for the repository member to get or push changes from or to the remote server. Basic naming for original remote server is origin.

3. Clone a Repository from Server

If you have an existing repository in server, it is possible to clone the repository to your local machine by using the following command.

git clone [repository-url]

After the repository cloned successfully, the repository will appear as folder in directory you run the command. The cloned repository already have repository initialized and origin remote at the repository-url. Make sure you cloned it from your own forked or original repository or have the repository access to be able to push the changes to the server.

4. Add file(s) changed in repository

After a changes was made in a file(s) inside the repository, the changes can be recorded as Staged changes by using the following command.

git add [path-to-content]

The content to stage can be a directory or a file(s). In directory case, every file in the directory will be Staged. To Stage all changes it is possible to use “.” or “*” as path to content.

5. Committing staged changes

After certain content added to Staged Changes, those content can be recorded in a form of commit.

git commit -m "[message]"

After running the command above, every content inside the Staged Changes will be recorded under the commit message. In GitLab, you can see every commit made in Repository -> Commits and what content changed under a commit.

Changes made in a file(s) under a commit

6. Stash your work

In case you have to push your current work, but some of it is not ready yet you can use the Stash.

git stash

By using the command above, your current directory will be saved for later use. This command usually used for changes that was not ready to be committed, yet you need to push your current work due to some situation. In the future, you want to continue your work then you can use this following command.

git stash pop

By running the command above, the stashed work will return and you can continue your interrupted work.

7. Creating a new Branch

It is possible that you need a different branch to develop a feature that was not needed by the others yet. By creating new branch, you can create a duplicate of your other branch and do your own work on the new branch.

git checkout -b [new-branch]

After you create the new branch, you will be automatically in the newly created branch.

8. Change to another Branch

Incase you want to change to another branch, you have to make sure that your previous work in your current work is staged or already committed. Then you can change to another branch in case you have to do a different job.

git checkout [target-branch]

9. See every Branch you have on your local computer

To see every branch you had in you local computer, you can do it by running the following command.

git branch

10. Delete Branch

Incase you want to delete your unused branch.

git branch -d [target-branch]

11. Merging your work from another branch (Merge and Rebase)

If you make a different work in a different branch in your local machine, it is possible to merge both work together. There is two way to do a merging, the first one is :

git merge [target-branch]

After running the command above, your current branch will have the changes made from target-branch. Do mind that doing a merge could cause a merge conflict if you made a different changes in both branches. In order to resolve the merge conflict, you have to accept the incoming (changes from target branch) or current (changes in current branch) or both changes (changes from both branch combined) to see which changes should be used on the conflicting file(s).

The second method to merge two different branched is by doing a rebase.

git rebase [target-branch]

Rebase will do exactly the same thing with Merge, but there is a little difference. The difference between Merge and Rebase is, Merge will have the commit sorted by timeline, while Rebase will stack the commit from target-branch right on top of current-branch commit.

Do be careful with rebase, due to it changed the structure of commit, by applying the changes in stack above the target-branch. Particularly in team based project, since rebase can change history and some confusing conflict.

12. Push the committed changes to remote server

After a commit(s) made in a branch, those commit(s) in branch can be pushed to the remote server with the following command.

git push [remote-name] [target-branch]

After the running the command above, all commit that has been made in the local machine will be pushed into the target-branch, changing every content in branch target based on content committed. If the target-branch is not available in the remote server, the target-branch will be made in the remote-server as well.

For example, there is empty test repository

Then, I made a README.md files on local. This file was not staged yet, so I can not push it to repository yet

Then right after, I staged the changes with commit. After staged the changes, I pushed the change to master branch of my remote repository.

Voila, the changes has been sent to repository, and you can check it online on your own repository!

13. Pull changes from remote server

In a group based project, it is clear what we need to get the work done by our colleague. In order to get the work done by our colleague in group project, we make a pull request from target-branch in remote repository.

git pull [remote-server] [target-branch]

After doing a pull request, the current branch will be automatically merged with target-branch from remote-server. Do mind the merge conflict is still possible to happen.

In case, there was a change on Remote Repository by yourself or another member, and you do not have the changes yet. You need to make sure to pull the changes to be able to get that changes.

Then to get the changes, we just need to pull it and the changes will be applied on your local repository.

14. Reverting a Commit

Sometimes, mistake happened and you already committed the mistake. Do not worry, you can still recover your previous work by reverting the commit.

git revert HEAD<~num>
git revert [commit-hash]

By doing a revert, the changes made my commit will be undone and then a new commit will be made containing the previously committed file(s). By adding ~num option like HEAD~3, you can revert the fourth last commit from HEAD, creating new commit without the fourth last commit from HEAD. Reverting the commit-hash will only revert the commit specified.

15. Reset a Commit

Reverting commit will produce a new commit, so the pre-revert changes will remain and can be tracked. Well you can get rid of those unwanted changes by doing a reset.

git reset [commit-hash]
git reset <HEAD<~num>>

Simple git reset will reset your latest commit back to when the commit was unstaged, the commit will be reset without overwriting the file(s) content. The second option will let you reset back to HEAD — num latest commit made. You can add another option like

git reset --hard <HEAD<~num>>

Do mind, using “-- hard” option will obliterate everything back to the basic! Be careful to use this option, because you could lose important changes you do not want to lose.

Incase we made some error, and we want to get back our pre changed file, we can easily do that with reset. First you need to check your commit hash with “git log” there will be list of commit with their hash. Then you can reset to the earliest or latest commit before change you wanted. Then you can remedy your mistake, and then push it back to remote repository by using “git push -f [remote][target-branch]”. But do note that “git push -f” can not be done on protected branch (in this case master is our protected branch). This example is a plain soft reset, so the changes will remain but the commit will be gone

Rejected push to protected branch, do another reset and push it to new branch

The changes has been updated on Remote Repository target branch

The previous commit prior to reset is gone

Well done, finally we reach the end of the ropes! I hope that this article will help anybody to understand Git better. I hope you guys have a good day.