Getting Good at Git

So, you’ve taken interest in software engineering. You could be in high school deciding on your future. Maybe you’re currently in college taking software engineering classes. Perhaps it doesn’t have anything to do with your education and you just want to learn a new stuff that could be fun, or maybe useful. Anyway, you worked hard and learned how to code, and now you want something solid. You want to work on an actual project, maybe with some friends that you’ve gained along the way. But . . . they come from faraway places. Meeting them is out of the question, so what do you do? One of them said, “It’s no problem, let’s just use git!” Everyone agreed, but you. “Hey, what is git?”

Git is a fast, scalable, distributed revision control system with an unusuall rich command set that provides both high-level operations and full access to internals. — Git Documentation

What does that mean in human language though? Basically, git is ONE way for software’s owners, developers, and users to track and manage changes to a source code. This definition is known by “version control.” Git is one (famous) method of doing version control.

Version control itself is one way for a group of developers to do “team coding”, as different individuals can contribute to various aspects in the software while having the versions monitored by everyone. Git is a way to do version control. Now, working in a certain controlled flow using git is called Git Flow — pretty self-explanatory, right?

So gitflow is a method of doing something, an abstract. But what exactly happens in a git flow?

Instead of working on a singular, conflict-prone version of a software (branch), gitflow uses several main branches that have a use on their own. The most popular gitflow is using at least two main branches called master and develop. The master branch stores the official release history, and the develop branch serves as a “stepping branch” for features.

In some versions of gitflow, there might be several other ‘main’ branches. As it happens to be, I am currently working on a college project that uses more. In my case, our project could use hotfix and coldfix. The hotfix branch would serve as the branch where we do quick fixes whenever bugs and errors surfaces from the master branch. The coldfix branch is meant as a “checkpoint”, that is, a version in which the recent changes are not implemented. A version which we would revert to whenever undesired changes are made.

Other than those main branches, we have the branches where everyone would put their hard work in, partially. They are usually called the feature branches. Each and every one of these branches is where the programmers code a single feature that has yet to be implemented in the develop/master branch. When the developers work in scrum (an agile framework), these branches would usually be assigned with the features from backlog items in each sprint — which is what I do in my currently ongoing project.

With all those branches explained, it really is not that hard to imagine the flow itself. Pogrammers work on each feature branches, each feature gets implemented into the develop branch if everyone agrees on the version, develop branch gets pushed to master branch when it’s time for “release.” Hotfixes and coldfixes are done as needed.

Okay, so now we understand how a gitflow flows. It’s time to learn how to ‘do’ the flow. Of course, before we begin, we need to have git installed. Don’t worry, it’s provided free here. The way we ‘do’ the flow is by typing commands in the git bash. So, let’s move to the directory of your software project, right click, and open the git bash there.

Opening git bash

I know, it looks similar to a command prompt which isn’t exactly exciting, but we’re all about functionality, right?

From here on out, it’s up to you to learn more about how git repository works. You can also check out which git website platform would suit you best for your project. There are plenty of stuff to learn and explore on your free time.

I said that we do everything by typing commands in the git bash, so let’s talk a bit about the commands. Sadly, we won’t be able to cover all available git commands out there, so let’s talk about the essentials. Go check out https://git-scm.com/docs/ if you are interested in the various commands.

• git clone <link>

Git clone is used to clone an existing git repository onto your local machine. An empty repository is also a repository, so that’s the easy way of creating a new project: create a project in a git platform (gitlab.com, etc.) and clone it to your device.

• git branch

As the command sounds, git branch is used to manage everything branch-related. We can look at the list of available branches by using --list. Git branch <name> will create a new branch, although this doesn’t immediately move us to that branch. We can also delete a branch by entering git branch -d <name>.

• git checkout <name>

Checks out to an existing branch. We can also create a new branch and switch to it immediately by typing in git checkout -b <name>.

• git pull

Incorporates all changes from a remote repository into the current branch. Using git pull by default (without arguments) is basically doing a fetch command.

• git push

Update the remote repository with the local one. This command is used to apply your commits to the remote branch.

• git merge

Incorporate changes from commits into the current branch.

• git revert

Create a new commit that reverts previous commits. This one requires your woking tree to be clean (no changes from remote).

• git rebase

Reapply commits to another base.

• git remote

Manage the set of ‘remotes’ whose branches you track. This command manages a lot of things and different flags will do different things. Go check out the documentation!

• git stash

This command is used to save your current work and ‘stash’ it away. After using git stash your working tree will be clean, but your previous work is saved and can potentially be recovered with git stash apply.

Those are more or less the git commands that you most likely will frequently use. Of course if anything is unclear, or you want to check the potential of every single command, you can always check out the git documentation here.