Git: The Best Time Variance Authority
This article is part of Proyek Perangkat Lunak (PPL) or Software Engineering Project Course. Any information written here may or may not be true. Please use it wisely and let me know if there is any wrong information in it.
[SPOILER ALERT]
Have you watched Loki season one? If you haven’t, maybe you won’t understand the joke. The way Git works is similar to TVA (Time Variance Authority). The difference is that TVA works with time and timeline while we work with code and branches. TVA’s job is to keep the time flowing as it should, while Git’s job is to keep our code working as it should. If you still don’t understand what I’m saying then let’s get acquainted with Git.
Git Oversimplified
What is Git?
Git is software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems). Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Source: https://en.wikipedia.org/wiki/Git and https://git-scm.com/about/distributed
There are 3 types of version control:
- Local Version Control Systems
Local version control system maintains track of files within the local system which means you can keep track of all the versioned files on your local computer. - Centralized Version Control Systems
In this approach, all the changes in the files are tracked under the centralized server. The centralized server includes all the information of versioned files, and list of clients that check out files from that central place. - Distributed Version Control System
It’s a combination between local VCS and centralized VCS. People still can collaborate on one system and if the server goes down, they can still save and access previous changes in their repositories and after the server is up again, anyone can back up to the remote server.
Getting Started with Git
Download and Installation
A complete guide on how to download and install Git is available on here and here
To verify that Git has been installed, go into your terminal and type:
git --versionBasic Workflow
There are three main components of a Git project:
- Repository
The repository, or repo, is the “container” that tracks the changes to your project files. It holds all of the commits — a snapshot of all your files at a point in time — that have been made. You can access the commit history with the Git log. - Working tree
The working tree, or working directory, consists of files that you are currently working on. You can think of a working tree as a file system where you can view and modify files. - Index
The index, or staging area, is where commits are prepared. The index compares the files in the working tree to the files in the repo. When you make a change in the working tree, the index marks the file as modified before it is committed.
Basic Command
- Git Init
This command is used to create a .git folder on the path you want to make a local repository. In other words, this command is used to create a new repository.
git init- Git Clone
This command is used to clone an existing repository into a new directory
git clone <URL> <new_folder_name>/*
You can let the <new_folder_name> empty
to use its default name
*/
- Git Add
This command is used to add files to the index (staging area)
git add <file 1> <file 2> …. <file n>/*
You can use . (period) to add all changed file to staging area
So the command will be git add .
*/
- Git Status
This command is used to displays a list of files that changed along with the files to be added or committed.
git status- Git Commit
This command is used to move files (commit) in the staging area to the local repository (HEAD). Any changes that are committed will not go directly to the remote repository.
git commit -m "<commit_message>"- Git Push
This command is used to move files from the local repository (HEAD) to the remote repository (server).
git push <remote_name> <branch_name>- Git Pull
This command is used to update working directory (local repository)with updates from the remote repository (server).
git pull <remote_name> <branch_name>- Git Checkout
This command is used to create a new branch or switch branches.
#Create a new branch
git checkout -b <new_branch_name>#Switch to existing branch
git checkout <branch_name>
- Git Revert
This command is used to return to a commit without deleting the commit history.
#You can find the commit id by using git log command
git revert <commit_id>Git Flow In Team: Merging vs Rebasing
As of the working flow or git flow, it depends on your organization or your team. There are some popular git flow such as merging and rebasing. But, in PPL we use merging flow. You can see the detail below
Merging
In PPL 2022 we have several branches, i.e.:
- Master
It is the main branch that stores source code ready to deploy into the production environment. The source code stored on this branch is the one that has been agreed upon, tested, and avoided from conflicts so that it is ready to be used by the user. - Staging
It is the main branch associated with the development process. This branch will store the source code of each developer’s work collected in one place. The application that will be used during the sprint review comes from this branch. - PBI[1..n]
It is a branch for the implementation of a Product Backlog Item retrieved in a Sprint. Later, there will be several Product Backlog Item branches named according to the name of the Product Backlog Item being developed. - Hotfix
It is a branch of the master branch that is created if there is a bug or error in the master branch. The hotfix branch is used as a place to fix bugs that occur in the master branch. After the bug is fixed and ready to be delivered, the hotfix branch is merged back into the master branch. - Coldfix
It is a branch created to perform a rollback (removing all changes from all product backlog item branches). This can happen if during a sprint review, the product owner refuses to release one or all of the product backlog items that have been implemented.
For each sprint, we work on a PBI (product backlog item) branch derived from staging. After getting our feature done, we can merge it into staging. If all PBI has merged into staging and the features look great, we can merge it into master which is the production branch. A merge request will be accepted (allowed to be merged with a staging branch), if it meets the following criteria:
- Passed testing
- Code quality that is met according to the standards set among group members
- It has been reviewed and approved by 2 group members.
Rebasing
In traditional merging process if we have a master branch then create a new branch without having changes in master branch then the merge process will be using fast forward merge, its called ideal merge because git only moves the pointer into the new commit.
But what happens if our master branch has another commit?
Then git will use three-way merge by creating new commit in master branch, that's why it called ‘merge commit’
Then what’s the problem with this merge process?
TADAAA!!! If you or your team have a lot of branches and commits, now your commit history will look like a train route and you will be confused when you see it.
Andddd this is where rebase comes to the rescue!!
The main purpose of using rebase is to avoid messy commit history and make history in a straight line so that it will be more readable. In short rebase is rewriting commit history.
Suppose we currently have 2 branches and we want to merge feature branch and master branch.
Assume you are currently on the feature branch, if you want to merge your feature branch with master branch then you need to do is
git merge master
# or
git pull origin masterWith merging, we will get the following result
But if you want to do rebasing, you need to type:
git rebase master
# or
git pull --rebase origin masterAnd with rebasing we will get the following result
Same with merging, if you get conflict on a commit, git will ask for our help to apply the correct changes. There is some option if you want to resolve the conflict
When you have resolved this problem, run "git rebase --continue".If you prefer to skip this patch, run "git rebase --skip" instead.To check out the original branch and stop rebasing, run "git rebase --abort".
The Golden Rule of Rebasing
Once you understand what rebasing is, the most important thing to learn is when not to do it. The golden rule of git rebase is to never use it on public branches.
For example, think about what would happen if you rebased main onto your feature branch:
The rebase moves all of the commits in main onto the tip of feature. The problem is that this only happened in your repository. All of the other developers are still working with the original main. Since rebasing results in brand new commits, Git will think that your main branch’s history has diverged from everybody else’s. So, before you run git rebase, always ask yourself, “Is anyone else looking at this branch?” If the answer is yes, take your hands off the keyboard and start thinking about a non-destructive way to make your changes (e.g., the git revert command). Otherwise, you’re safe to re-write history as much as you like.
Git Rebase Pros and Cons
Pros:
- Creating a cleaner history repository
- Easy to read commit graph
- Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams.
- Avoids merge commit “noise” in busy repos with busy branches.
Cons:
- Rebasing can be dangerous! Rewriting history of shared branches is prone to team work breakage.
- It’s hard to revert code because it deletes some history
How it’s going on PPL?
Actually, git is easy to use until…
Yeah, in PPL this is a common thing to happen. How do you resolve it in PPL?
Actually, Git offers several ways to resolve conflicts:
- Accept current change.
- Accept incoming change.
- Accept both changes.
In PPL cases, mostly we use accept both changes because sometimes we work at the same file at once. But the most important tip is to discuss with your friends which lines need to be kept and which lines need to be deleted.
Other very helpful GitLab features
Maybe some of us are used to using Jira, but it turns out that GitLab also has some features that are similar to Jira that is issue and board, user story is same as issues in GitLab, and the board is same as agile board.
Issues and GitLab Board
User story is a description of the needs of a feature from the user’s point of view. In gitlab we can create an issue and put it on the board to set the status.
Final Words
Git has an important role in team collaboration. There are many things we can do with Git and tons of interesting Git flow and features out there. Although Git is complex and difficult to learn for some people. Git is still very powerful and provides many benefits to its users, especially when working as a team.
Thanks for reading and don’t forget to be grateful!
“Teamwork is essential, it allows you to blame someone else”
- Of course not me
