Git, Magical Tool Used by Software Developers

9 min readFeb 27, 2022

Yupp, it is Git. The magical things to handle projects with more than 1 person. Git is mostly used by software developers to develop projects together. The main function of git is to control the version of the source code by marking which line of code that replaced or added.

Why this tool is important and is called magical things?

Software development with several programmers' code in the same source code is complicated. Several programmers do this module and add another function to that module while another programmer also builds the same module at the same time. Developing software with version control like Git, the changes will be saved automatically, and another developer doesn’t need to worry about the update on the source code. So, we don’t bother waiting for someone to fix module A while the others can continue developing module B.

In this article, I will give you some basic tutorials and use cases to use git and its command. But, before we go through it, I hope you’ve already installed Git and set up your account.

1. Clone a Repository

So, the first thing you need to do is set up a remote repository to your local computer.

You can choose option to clone using SSH or using HTTPS. Using SSH is preferably if you are often used your git account. It is safer and mostly used by software engineers. Using HTTPS also fine, but you need to save your account info in your git project, your account info including your username and your password.

You can do clone using git clone <url> command.

2. Develop and create changes for yourself

Use Case:

You want to develop new feature such as login. But, you don't want your teammate change the source code because you’ll need to pull it from main and the changes from your teammate could interfere with your feature your are developing.

Solution: Create new branch from the main branch, you can do this by calling

git checkout -b <branch name>

Branch is separated place from the main source code where you can safely make changes and commit without having to think about changes from other developers. There are several command about branch:

Create new branch git branch <branch name>
Checkout to available branch git checkout <branch name>
Create new branch and checkout to that branch
git checkout -b <branch name>
Delete branch from repository git branch -d <branch name>

So, this is scenario. You wanna to develop payment feature, but your teammate also developing refund feature. Both of you working in same module called Payment . You can use branching in git.

You create new branch called feature/paymentfrom main branch and checkout to that branch using git checkout -b feature/payment
Your teammate also create new branch called feature/refund from main branch and checkout to that branch using git checkout -b feature/refund.
Both of you can develop your feature in your own separated branch without breaking each other works.
Both of you push your changes to each branch and you won’t bother to sync with each other changes or pull first before push.

3. Pull changes from remote repository

You need to get the changes your teammate made from other branch that already in main branch, but you don't have the update yet in your branch.

You can pull the changes from main branch to your branch. You can use git pull command to pull from remote. For example, the remote URL name is origin and the main branch is main . You can use command git pull origin main to pull changes/update from branch main.

This git pull command can pull changes from all branches. For example, you want to test your payment feature with your teammate’s refund feature. This step is suggested if you wanna to test feature that haven’t already merge to main yet.

You create new branch called test/payment-and-refund from your current branch feature/payment using git checout -b test/payment-and-refund
You pull changes from your teammate’s branch’s named feature/refund using git pull origin feature/refund
Finally, you have your teammate’s changes in another separated branch just dedicatedly for testing.
And you can get back to your branch using git checkout <branch name>

4. Merge branch with merge request

After you done developing your feature in separated branch, you need to merge your work to main branch.

For this scenario, you can use command git merge but it is preferably to use feature called merge request in gitlab or pull request in github. This can be done using GUI provided by the platform.

For example, the image below is merging changes using merge request in gitlab.

Merge Request example in GitLab. You see that the merge request needs 1 approval in order for it can be merged to the main branch.

Using merge requests can be beneficial to your team’s development. Each one of you can make sure other’s work by reviewing it and make approval of ones work. Also, people can see your changes and add comment about your code along giving suggestion that something need to change.

Example of commenting with suggestion of changes.

5. Solve merge conflict

You already done developing payment module and you want to merge your changes to main branch. But, unfortunately, your teammate changes already merged to main branch and when you try to merge request it appear to be conflict.

Example of conflict caution in merge request Gitlab.

This can be happening in a software development project, regularly.

Why is this case occur??

This happens because you, for instance, trying to change something in the exact file and exact line of code same as your teammate does. Your teammate’s commit is already being merged to main and when you try to merge, it will occur as conflict. Do not panic when this happens to you!

There are multiple ways to solve this

a. Use resolve conflict GUI from the platform

This can be done by using their option about Resolve conflicts and they will bring you to their GUI. It has 2 modes, interactive mode and edit inline.

In interactive mode, you can pick whether to use your own changes or others’ changes.

If you want to combine and fix the conflict. You can use edit inline and fix the conflict by your own desire.

b. Resolve conflict locally (using VSCode)

By resolving the conflict locally, the actual doing is you pull the updates from main branch and you fix the conflict using your own lovely code editor.

For this scenario, I am using VSCode and it has Git extension so that you can developing your project with Git more comfortable.

First, pull the updates from main branch using git pull . It will give you response if the changes you pull result in conflicting with your codebase.

Then, you can fix the code in your lovely editor and you can choose or edit as your own concern about the merging.

Finally, after you fix all those conflicts, you need to commit the changes and push to your branch. If you succeed to do this, the merging conflict caution will disappear.

6. Git Rebase

You are developing payment feature. In your feature branch, you are experimenting or often doing trial and error to your source code. You are often to commit with your trial and error and it makes your commit not relevant to the main feature. You wanna make your commit clean when it merges to master.

Solution: git rebase

Git rebase serves to move the entire commit history of a branch to be echoed to another head branch. The difference from git merge, git merge merges all the last states of the two branches, while rebase removes commit history.

# Commands (from git rebase manual):
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit

Some notable ones that may be used frequently:

pick (p): choose this commit as is
drop(d): delete this commit
squash(s): merges the changes of this commit with the commits that follow.

In that commit, I would like to merge commit with comment fix linter and change black gitlab ci . So it will be like this

Hence, the commit message will be cleaner like this

8d96339 fix sonar issue and refactor error handler
bce3eed fix linter
283b8ad change black gitlab ci
7490fa4 fix type(T) bug vurnerability
c2c3793 change gitlabci for pytest
c694a1f fix gitlab ci sonarqube in dev branch
96e2ef7 fix sonarqube ci error
3e38e04 fix linter

Caution

It can completely change your commit history and can cause problems that are very difficult to fix if other branches are dependent on the rebased branch. Please only use this command on changes that occur only on your branch and make sure no branches are dependent on this branch.

7. Git Workflow

Now, after you understand about basic git command, there is some git principle or workflow that you are nice to have if and must know if you developing large projects. Some developers perhaps have their own ways about developing their projects using Git. But, here I share about my workflow when developing large projects with number of people involved.

In the large project, we typically have a prod (production) branch, dev (development) branch, and then feature branches. If you think of a website, the prod branch is the actual website that is shown to the world while the dev branch is where all the developers make changes, which are not ready to be shown to the world. Developer are working in a dev branch, adding on new changes to whatever is already in prod. Then when they are satisfied, they launch all the changes onto prod at once to have a full new coherent version of the product. In my scenario, the dev branch usually the master or main branch, this branch is where developer will have their feature merged.

Then lastly, we have the feature branches. Each feature branch, in theory should only have one person working on the branch. If there are features that require more people working on it, continue branching from that branch until only one person is working at a “leaf” branch at a time. As the name suggests, the feature branches should be isolated branches in which a developer creates a new feature. Once the feature is completed, it is merged into dev for all other developers to see. Then lastly, all the changes to dev will eventually be merged to prod for a new version of the product.

Branch development illustration, taken from Kofax

A developer should never commit or push to dev directly, and even more so NEVER EVER commit or push to prod directly. It is ok for dev environment to go down every once in a while or crash, but production should never go down.

Finale

Git is cool and magical tools that often used to software development. Actually this tools can be used to other development as it is called version control. When working in large software, you are preferably using git to develop them. It will help developer isolating their code from other’s work while they working on the feature. It is recommended to have your commit message more explainable that can help other developer understand what were you doing in those commits.

Anyway, now you have all the tools needed to work on a Git project with other people. Good luck and have fun with any merge requests!