[tutorial] Git Survival Kit pt.1: Covering the basics

Welcome to our brand new tutorial: Git Survival Kit series of posts! Before you start reading, a word of caution: this is not a comprehensive guide of Git. Instead, I’ll try to summarize some of the most useful Git commands with respective use case scenarios. This guide is suitable for everyone and doesn’t require any previous knowledge of Git to understand it. However, if you’re already familiar with some of the material, feel free to skip to the part which interests you. In the first part, I will cover some Git basics which include setting up a Git repository, making changes and committing them. You will also learn how to view your changes and commit history. Let’s get underway then.

What is Git?


 

Git is a version control system (VCS) which tracks and records changes to your project files over time. Basically, it allows you to change between different versions of your project in a flash. Furthermore, it also enables simultaneous collaboration on the project.

Every time you save the state of your project, Git stores a reference to your current data (snapshot). When you commit or save your state, Git calculates a checksum (SHA-1) that provides data integrity and a way to refer to data.

To store its data, Git uses repositories. Most often, you work using your local repository. When you want to share data with other members of your team, you push it to an online repository. Contrary to that, when you want the newest changes, pull them from an online repository. So first of all, I will explain how to set up a repository.



You can do most of the stuff on your local machine, even without a network connection. Don’t be afraid to experiment, that’s the best way to learn!

Setting up a repository


 

You can set up a Git repository using two different approaches:

  • By cloning an existing repository
  • By initializing your local directory as a Git repository

 

To clone a repository means to copy almost all data from the server to a local directory. So to do that, use:

git clone <url> <directoryName>   

If you omit the <directoryName>, Git will name the directory according to the project name.

$ git clone https://github.com/AMBES/importantProject localRepository
Cloning into ‘localRepository’…
remote: Counting objects: 23257, done.
remote: Compressing objects: 100% (22213/22213), done.
remote: Total 23257 (delta 5012), reused 17993 (delta 832)
Receiving objects: 100% (23257/23257), 185.92 MiB | 2.91 MiB/s, done.
Resolving deltas: 100% (5012/5012), done.

Your local repository is now set up and you can work on it or use it straight away.

 

If you want to initialize a new Git repository in your project folder, use:

git init

The result is that Git initializes a repository, but doesn’t track anything yet. Next chapter will explain how to change that.

Making changes to your local repository


 

Each file in your working directory can be in one of two states: tracked or untracked. Tracked files go into snapshots and can be either unmodified, modified or staged.

To see the status of files in your working directory, use:

git status
$ git status
On branch master
Your branch is up to date with ‘origin/master’.

Changes not staged for commit:
(use “git add <file>…” to update what will be committed)
(use “git checkout — <file>…” to discard changes in working directory)

modified: coolClass.cpp
modified: someLessCoolClass.cpp

no changes added to commit (use “git add” and/or “git commit -a”)

To start tracking new files and to stage modified files for commit, use:

git add <file>

You can use git add on both files and directories. If you use it on a directory, it adds all the files in that directory.

To stage all files in your current working directory, use:

git add .


If you change a file that was already in the staging area, you have to stage it again to commit the latest changes.

Viewing changes


 

To see what files you’ve changed, but not yet staged, use:

git diff

This compares your working directory with the staging area. As opposed to git status, it also shows which lines of code you’ve added and removed.

 

If you want to see the difference between the staged files and your last commit, use:

git diff --staged

Committing changes


 

To commit the changes you’ve made, use:

git commit

This opens your default console text editor which enables you to write the corresponding commit message. To change the editor, use:

git config --global core.editor <editor>


It is important to remember that you commit only those changes that you added to the staging area

You can type your commit message inline with the -m option:

git commit -m "Commit message"
$ git commit -m “Do NOT write commit messages like this”
[master bd3b6270] Do NOT write commit messages like this
2 files changed, 3 insertions(+))

It is important to write commit messages the correct way. You should:

  • leave a blank line between the subject and the body
  • capitalize the subject line and limit it to 50 characters
  • use the imperative tone in the subject
  • wrap the lines in the body to 72 characters
  • explain what and why you’ve changed, not how

 

To cut some work, you can stage all tracked files and do a commit at the same time using the -a option:

git commit -a

Viewing the commit history


 

To display all commits in reverse chronological order, use:

git log

The command displays each commit with its message, checksum, author details, and date.

$ git log
commit bd3b62706d1f72f169f4427cb9ed56a6483ffb6a (HEAD -> master)
Author: Marko Jovic <marko.jovic@ambes.de>
Date: Thu Nov 8 10:57:53 2018 +0100

Bugfixes to the very important commit

commit 621c32373c9d3ebc9c38b19137bd4291e477d879
Author: Ivana Soric <ivana.soric@ambes.de>
Date: Wed Nov 7 14:39:11 2018 +0100

Very important commit

To display the difference that each commit introduced, use the -p option:

git log -p

If you want to see the stats for each commit, use the –stat option:

git log --stat


Stats include the number of files changed, insertions and deletions

To specify a different output log format, use the –pretty option.

For example, the oneline value displays each commit on a single line:

$ git log –pretty=oneline
bd3b62706d1f72f169f4427cb9ed56a6483ffb6a (HEAD -> master) Bugfixes to the very important commit
621c32373c9d3ebc9c38b19137bd4291e477d879 Very important commit
f7d0b57eefd194c4a5b0d014a9fbd768fbe0e844 Bug fixes.
dc55d4223bcd4ef28bab28579101eb698180268f Tested audio
47f27fd4f4639dfa4638b4871ca3558509a474fe Added Audio classes
7da7f68ff61f6800ac11c1848881fb675fef1537 Fixed Config

The format option lets you specify your own output format.

Another handy option is –graph because it shows your branch and merge history as an ASCII graph:

$ git log –pretty=oneline –graph
* bd3b62706d1f72f169f4427cb9ed56a6483ffb6a (HEAD -> master) Bugfixes to the very important commit
* 621c32373c9d3ebc9c38b19137bd4291e477d879 Very important commit
|\
| * dc55d4223bcd4ef28bab28579101eb698180268 f Tested audio
| * 47f27fd4f4639dfa4638b4871ca3558509a474f e Added Audio classes
| * 7da7f68ff61f6800ac11c1848881fb675fef153 7 Fixed Config
* | f7d0b57eefd194c4a5b0d014a9fbd768fbe0e84 4 Bug fixes.
|/
* cf15745de80b6539070da7eecc86582d88829e25 Daily commit

Furthermore, you can limit the log output. To show only the last n commits, use – option. If you want to limit the output to a certain time window use the options –since and –until.

The last one that I’m going to mention is the -S option. It allows you to pass a string and shows only those commits that include the changes of that string. For example, to track changes to a variable, use:

git log -S variable_name

And that’s it for the first part of our Git survival kit series. In the next part, I will talk a little about branching, remotes and how to undo stuff.

Marko Jovic

Post a Comment

Comment
Name
Email
Website