Git from scratch — 5 steps guide

Introduction

“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. Git is easy to learn and has a tiny footprint with lightning fast performance.” (Git)

But first thing first : what is a “version control system”, and why should we care?

A version control system (VCS) tracks changes to files. As we modify files, the system records and saves each change within an history. This allows to restore a previous version of your code at any time. Using a VCS also generally means that if we screw things up or lose files, we can easily recover to any checkpoint.

In a collaborative environment, it is common for several developers to share and work on the same source code. While some developers will be fixing bugs, others will be implementing new features, etc. Git is the standard system used to manage all of this.

In short, a version control system like Git is essential for all kind of programming and software development. It makes it easy to:

- Keep track of code history
- See which changes were made
- See why were changes made
- See who made which changes
- Collaborate on code as a team
- Deploy to staging or production

We will learn here Git from essentials like repositories, branches, commits, and Pull Requests to more advanced topics such as workflow, statistics, automatic build integration and how to collaborate with other developers.

What if I don’t use it?

I am sure any of us has already been doing some file renaming to keep track of different versions, as for instance : “resume”, “resume_v2”, “resume_062018”…

In other words, any of us has already been stuck to manually save multiple versions of files using different names. Renaming a file also doesn’t give us any context as to what changes were made or who they were made by. When multiple team members edit the same file, overwriting occurs and it starts being impossible to keep up with the latest file version.

This problem already occurs for a unique file. I let you imagine how messy it can be with thousands of them.

Why using Git in particular?

The very short answer would be : Git is the most widely used version control system in the world and is considered the modern standard for software development.

Unlike older centralized version control systems such as SVN and CVS, Git is distributed: every developer has the full history of their code repository locally. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

Git also has excellent support for branching, merging, and rewriting repository history, which has lead to many innovative and powerful workflows and tools. Pull requests are one such popular tool that allow teams to collaborate on Git branches and efficiently review each others code.

Great, since we know for what and why we are using Git. Let’s get started!

Simple guide — 5 steps

This guide is a simple and practical introduction to start working with git from scratch. Here, we will go straight to the point. This step by step guide to a Git workflow aims to help give an introductory overview for managing any project.

Let’s get started on using Git now.

1. Installation

Git for Linux

Git for OSX

Git for Windows

Verify if Git is installed by using the following command in the command prompt:
git --version

2. Create or get a repository

To start working on a Git repository, you have the choice to either create a new one or use an existing one (from GitHub for instance).

Create a new repository

create a new directory, create a directory and perform a
git init
inside to create a new git repository.

Checkout a repository

create a working copy of a local repository by running the command
git clone /path/to/repository
when using a remote server, your command will be
git clone username@host:/path/to/repository

3. Save our changes

Our local repository consists of three “trees” maintained by git.
The first one is your Working Directory which holds the actual files.
The second one is the Index which acts as a staging area.
And finally, the HEAD which points to the last commit we have made.

A. Commit

Note : Git comes with built-in GUI tools for committing — git-gui. We recommend you to use it in order to avoid being struggled with the command line. You just have to launch it within your repository:
git gui

Add & commit

You can propose changes (add it to the Index) using
git add <filename>
git add *
This is the first step in the basic git workflow. To actually commit these changes use
git commit -m "Commit message"
Now the file is committed to the HEAD, but not in your remote repository yet.

B. Push

First thing first, we need a host (such as Github, Gitlab, Bitbucket…) to put it online. If it has not been done yet, just create an account on one of this platform.

Pushing changes

Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
git push origin master
Change master to whatever branch you want to push your changes to.

If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
git remote add origin <server>
Now you are able to push your changes to the selected remote server

The full workflow results as the following:

4. Branching

A. Branches

Branching allows each developer to branch out from the original code base and isolate their work from others. It also helps Git to easily merge versions later on.

Imagine that you are working with your colleagues on the same file. There is a solid chance that someone will, at least partially, overwrite one other’s work. We can avoid that by branching in order to isolates our work from that of other team members.

In short, a Git branch is an independent line of development.
Note: each node on the image above represents a commit.

Branches

The master branch is the “default” branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.

create a new branch named “feature_x” and switch to it using
git checkout -b feature_x
switch back to master
git checkout master
and delete the branch again
git branch -d feature_x
a branch is not available to others unless you push the branch to your remote repository
git push origin <branch>

Note : Git comes with built-in GUI tools for browsing — gitk. We recommend you to use it in order to get a good overview of your branches. You just have to launch it within your repository:
gitk

B. Update & Merge

update & merge

To update your local repository to the newest commit, execute
git pull
in your working directory to fetch and merge remote changes.
to merge another branch into your active branch (e.g. master), use
git merge <branch>
in both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
git add <filename>
before merging changes, you can also preview them by using
git diff <source_branch> <target_branch>

Reverting changes

If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this:

Replace local changes

git fetch origin
git reset --hard origin/master

5. Extras

Tag & Version

It is recommended to create tags for software releases. You can create a new tag named Hurna v1.3.0 by executing
git tag -a v1.3.0 -m "Hurna v1.3.0"

Log

in its simplest form, you can study repository history using
git log
You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain author:
git log --author=michael-jeulinl
To see a very compressed log where each commit is one line:
git log --pretty=oneline
Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:
git log --graph --oneline --decorate --all
See only which files have changed:
git log --name-status
These are just a few of the possible parameters you can use. For more, see
git log --help

Wonderful! If you get this far, you master everything you need to manage a project and its versions. The next courses are about putting everything into advanced practices.

Here is a list of some more Git commands to get you going with Git in a day-to-day workflow: https://hurna.io/academy/git/general_commands.html