This time we'll talk about the literal backbone of working on a software engineering project as a team: version controlling with git. I've used git since my freshman year, so I know my way around it (more or less).

There are loads of advanced git techniques out there, but I can say that I'm pretty fluent with git, at least for the basic commands and workflows. Here's a cheatsheet, along with how I (and my team) use git for our workflow.

Overview

Git is one way of version control. It's like looking at a version history on google docs. It also serves the purpose of sharing your files with your team members with ease. You no longer have to copy your files to a USB stick and hand it over to your friend, or email them, or anything of the sort. Everything is stored, accessible, and up to date in a remote repository where everyone can contribute their changes almost simultaneously.

Well, at least that's how I would explain how git works without looking at the wiki or the official docs. To be completely honest, I don't know the nitty gritty innerworkings of git at all. But I know that it makes my life easier–and maybe soon, yours too.

How to Git Gud

There are some steps to git gud. I'll start at the very beginning, a very good place to start. When you read, you begin with ABC. When you use git, you begin with git init.

But not really.

Set up

Install

Before you can actually use git on your machine, you have to install it first. Download and install git using the instructions provided here according to your operating system.

Initialization

Then we can begin with git init. Move to your project directory and use this command to initialize a local git repository for that folder.

cd path/to/your-project
git init

Identity

You should tell git who you are. This will be the information shown as author in the commits you make in the future. Provide a name and an email and set them in your config.

git config user.name <your_username>
git config user.email <your_email>

Connect to a remote repository

Next step is usually done in the beginning of every project. You create a remote repository, in our case we chose gitlab CSUI as it was provided by our faculty, and connect it to our local repository.

You can do that in two ways: cloning your remote repository, or adding an existing repository as a remote. Cloning works pretty much the same way as downloading. You can also clone a particular branch of the repository by adding the branch name as an argument. Otherwise, the default branch will be cloned, this will either be the master/main branch.

git clone <repository_url>
git clone <branch_name> <repository>

If you're starting from scratch, you'll usually need this command. It connects the remote repository with your local one. The <repo_identifier> is technically up to you, but I never stray away from either origin or upstream.

git remote add <repo_identifier> <repository_url>

Make changes

Now that we've set up our git repository, time to make some changes in the project.

Add files to stage

To prepare for your first change, you need to add the files you changed to stage. This is done by the following command. Choose according to your situation.

git add .
git add <single_file>
git add <file-1> <file-2> <file-3> <file-n>

Commit changes

Save your progress by commiting your changes. Write a commit message that is clear and concise. This serves in describing what changes you made within this commit.

git commit -m "<commit-message>"

If you found some file that you forgot to add to a commit, or you want to change the commit message, you can use the following command.

git commit --amend -m "<revised_commit_message>"

Save WIP changes

If for whatever reason you need to switch to another branch while working on something, or that you want to scrap your progress but have it stored somewhere you can go back to, you can 'commit' your progress to a stash.

git stash

More useful commands relating to git stash is as follows. pop lets you continue working with the stashed commit and drops it from the progress stack. apply lets you continue without dropping it from the stack. drop will throw away the last progress you stashed. Use them accordingly.

git stash pop
git stash apply
git stash drop

Synchronize

Now, because we got a lot of people working on the same codebase, there ought to be some synchronizing done.

Remote to local

To 'download' remote changes to your local repository, use the following command. It's used in the case of someone (usually your team member) pushing some changes to the remote.

git pull <repo_identifier> <branch_name>

If you only want to keep track of the branches in the remote repository but not pull the changes, you can use the following command instead.

git fetch <repo_identifier> <branch_name>

Local to remote

This is similar to 'uploading' your changes to the remote repository so your fellow team members can access your changes.

git push <repo_identifier> <branch_name>

Avoid using --force unless you absolutely know what you're doing. Bad thing happens.

Branching

This part is one of the most important parts in working with git in a team. Branching can be used to separate changes made for different contexts. For example, someone who's working on the auth feature will have one branch exclusively for that feature. This way, changes are not overlapped when the progress is still going on.

Create branch

To create a new branch from the current point, use the following command.

git checkout -b <new_branch_name>

Move to another branch

git checkout <branch_name>

Delete branch

You may want to delete unused branch, or an old one that's no longer relevant. Use the following command.

git branch -d <branch_name>

Combining branches

In an ideal environment, you would submit a merge request before merging branches into one. To do it locally, you can use the following command.

git checkout <target_branch>
git merge <source_branch>

Or, with rebase, use the following command. Rebasing assures that you have all the changes in the target branch before merging your changes from the source branch.

git checkout <source_branch>
git rebase <target_branch>
git checkout <target_branch>
git merge <source_branch>

Avoid Oopsies

Sometimes, oopsies happen. You can always prevent them from happening (or prevent others from knowing that they happened).

Check current state of git

The following command tells you the current branch you're on and all changes you have made, both staged and unstaged.

git status

git reset

This command erases the commit you've made. I've used this command more lately, but if you're just beginning, use this at your own risk.

git reset <commit_hash>

git revert

The following command lets you roll back to a previous commit without erasing any commit before it. Use this when you've pushed your changes to the remote repository.

git revert <commit_hash>

Git Workflow of Ajaib on DEX

My team and I use git as the base of our workflow, including PBI organizations and such. We agreed on some guidelines at the beginning on how we should write our commit message and fill out our merge request forms. This way, everyone can easily understand what the other are doing–with minimum misunderstanding.

My team’s graph

Commit Message Rules

We write our commit messages in this format: [TAG] Chages description. [TAG] is mainly one of these four:

• [RED] - used after writing failing tests
• [GREEN] - used after passing test with minimal implementation
• [REFACTOR] - used for refactoring code within passing tests
• [CHORE] - used for mundane tasks like moving files or updating config files

Sometimes I forgot to use the tag (because I usually use gitmoji) but I fixed that on the successing commits.

Making Merge Requests

Our merge requests coincide with the PBI we're working on in the current sprint. The title describes which PBI we're working on and a short description on which part is done. Here's one of the merge requests I've submitted.

The merge request I submitted for a UI component

I provide a background, usually the description of the PBI or task itself. Then, I list the changes I made, as well as screenshots of the UI component if there was anything to display.

After this, my team members would review the changes I made and make comments or request for changes so we can assure the codebase is generally clean of spaghetti.

TL;DR

Git requires a lot of practice to be fluent in, just like any other language. After using it a lot, these are the main command I use very frequently.

git init
git add .
git commit -m "<commit_message>"
git push origion HEAD
git checkout <branch_name>
git rebase <branch_name>
git reset --soft <commit_hash>
git merge <sourch_branch>

That's all I have for today. I desperately need a good night's sleep 💀💀💀 Thank you if you've read everything thus far.

See you on the next one~