Gitty Up, Let’s Go!

8 min readMar 18, 2021

In case you didn’t get the reference, it’s from the Christmas song Sleigh Ride:

Giddy up giddy up giddy up, let’s go
Let’s look at the show
We’re riding in a wonderland of snow

I’ve been using git for more than two years now, but I still find it amazing how it can literally save a developer’s life. (Okay, more like figuratively, but still.) It has saved me at least hours of exasperation and ugly crying. That said, using git for the first time can be overwhelming, so let’s take a look at some git commands that you should know before starting your git journey.

What Is Git?

Git is a version control system that lets you track the changes that are ever made to a project and revert to an older version should you need to. It’s also very useful when working in a team since it allows multiple people to easily collaborate on the same project.

The Basics

To start using git commands on your project, you need to run this command inside your project directory on the terminal or command-line interface.

git init

For demonstration purpose, I have created an empty project called git-project. Let’s try running the above command and see what happens.

You have successfully initialised a git repository. Congrats!

So you’ve made changes to your project, and you want to put them into your remote repository. Before doing that, you need to stage the files. The staging area is a place to keep track of everything you want to commit. Here is the command to do it.

git add <file-name-1> <file-name-2>

Feel free to add as many files as you want, or if you want to stage all the modified files in your local repository, simply use this command.

git add .

If you want to check which files you have modified, you can use the following command to see the current status.

git status

I have created two new files in my git-project directory, so they should appear when I check the status.

There they are. Now, I want to stage both of these files. Since there’s nothing that I want to exclude, I’ll go ahead and stage everything.

Great, now you’re ready to make your first commit. Make sure to add a meaningful comment along with it.

git commit -m "this is a commit message"

For example, you can describe what files you have added.

Before pushing your code, you need to specify a remote — the URL to a copy of your repository on the internet. Head to a git hosting platform (usually GitHub or GitLab), create an online repository and copy the URL to use in the command below.

git remote add origin https://github.com/username/repo

I have created an empty repository on my GitHub account. Let’s try adding it as a remote repository for git-project.

One last step, and you’re good to go. You need to push your commits into the remote so that they can be accessed on the internet.

git push origin master

You might be asked for your GitHub username and password when trying to push for the first time, as shown below.

That’s it! You have successfully made a copy of your project on a remote repository.

Now you might be asking yourself, what if I want to copy someone else’s code into my own machine? Well, the thing you’re looking for is cloning. To clone a repository, note the repository URL, and use the following command.

git clone https://github.com/username/repo

You can now make your own changes to the project on your local machine.

Branches

When you’re developing a project as a team, many things can go wrong. Imagine how disastrous it would be if everyone made their own changes, and all the commits were combined into one place. Fortunately, git has this feature called branch. Simply put, branching means taking a turn from the main path of the development, so your work doesn’t affect the main path until they are merged. To do this, you can use the following command.

git checkout -b <your-new-branch-name>

In this example, let’s try creating a branch called development.

After modifying the files safely on your branch, you’ll want to combine the changes back into the main path — the master branch. First, head back to the master branch.

git checkout master

I have created a new file on branch development and committed the change. Now we can go back to the master branch.

There are two ways to combine these two branches. The first one is merge, which takes the source branch’s contents and unites them into the destination branch. It’s worth noting that merging keeps the chronological order of the commits and creates a new commit that has the history of both branches.

git merge <your-branch>

On the other hand, rebase applies the commits from one branch on top of the other one’s latest commit. This is a “cleaner” alternative to merging since the history is flattened.

git rebase <your-branch>

Now that you know the differences between merge and rebase, you might be wondering which one to use in different scenarios. Here’s an easy rule to follow. If the changes you’ve made are significant and your teammates need to be aware of the things you’ve done, it’s usually better to use merge so that they can see the entire commit history. On the other hand, if you’ve only made minor changes and the commit history is not that important, you might want to use rebase for its clean result.

For this example, let’s try merging the development branch to the master branch.

The change in the development branch is now applied to the master branch as well.

Undoing Things

If you’re clumsy like me, chances are you’ll experience almost having a heart attack because you make a mistake on your commit. The good news is git is powerful enough that it lets people like us undo when things go wrong.

When you just want to discard the changes you haven’t staged, you can use the following command.

git checkout <file-name-1> <file-name-2>

Or this one, if you want to discard all of the modified files.

git checkout .

For example, I have two modified files in my directory, but I changed my mind, and I want to undo the change I made to the file called development.md.

Notice how the output of the second git status is different from the first one.

Now, what if you changed your mind after staging the files? You can use the following one to undo staging a file.

git reset HEAD <file-name>

To undo staging everything in the staging area, use this one.

git reset

Like working with uncommitted files, you can make sure that it works by running the git status command.

Okay, but what if you made a mistake on a commit? If you just want to change the commit message or add more changes, amend is your best friend. To add more changes, just stage them as usual before executing this command.

git commit --amend -m "the right comment"

In this example, let’s try committing a wrong message and correcting it. Then check the git log to make sure that the message is changed.

Nice, it worked like a charm.

However, if you really need to undo a commit, you can do it with the reset command. Do a soft reset if you’d like the changes to be preserved.

git reset --soft <commit-id>

If you don’t want to keep the changes, do a hard reset.

git reset --hard <commit-id>

Besides using the commit id, you can use the following to undo your most recent commit.

git reset --soft HEAD~1

Now, let’s try using the above command to undo our last commit. We’ll check the log to see if the commit has disappeared.

Summary

To sum things up, here are the fundamental git commands and what they do.

git init: initialises a new git repository
git add <files>: adds new changes to the staging area
git commit -m <message>: creates a new commit that includes files in the staging area with a commit message
git push: adds new commits to the remote repository
git clone: copies a remote repository to the local machine
git checkout -b <branch>: creates a new branch
git checkout <branch>: moves to another branch
git merge <branch>: combines two branches by creating a new branch that keeps the history of both branches in chronological order
git rebase <branch>: combines two branches by adding the commits from one branch on top of the other one’s last commit
git checkout <files>: discards changes
git reset: removes files in the staging area
git reset <commit id>: reverts back to the specified commit

Conclusion

You have now learned the common git commands that you need to know to start working with git. Git is very helpful when it comes to collaborating in a team, but working with git is not always rainbows and butterflies. Conflicts happen — more often than you’d like — and sometimes there is much work to do to solve them. That said, keep in mind that these things happen to prevent more severe damage from occurring. All in all, git has helped me a lot, from collaborating to automated deployment. There are many more things to learn about git, and there are a lot of resources on the internet.

I hope you found this helpful. Thank you for reading!

This post is written as an assignment for the PPL course at the Faculty of Computer Science, UI.