Git- Part 1: Intro to Git

Introduction: What is Version Control?

● Version Control System (VCS) is a system used for tracking

changes to content (aka source control).

● Crucial for collaboration:

◆ Who made the change?

◆ What was the change?

◆ When was the change made?

◆ Why was the change made?

● In short, a VCS keeps track of history. Great for code reviews and

reversion.

● Source Configuration Management (SCM) != VCS

SCMs include the building, packaging, and deployment of code.

● What content should I store in source control?

Really just source code specific to the repository.

● General Rule of Thumb: Don't store anything that is generated

( logs, binaries, 3rd party files, etc )

 

Introduction: What is Git?

● Linus Torvalds (inventor of Linux) started working on Git in 2005

when the Linux Kernel needed a new Version Control System.

● He started searching for a replacement for BitKeeper.

◆ Needed to be Distributed

◆ Needed to be Fast

◆ Needed to ensure Data Integrity

I decided I could write something better than everything out there

in two weeks….and I was right. - Linus Torvalds

● Linux and GIT are egotistically named after Linux himself

(git = slang for arrogant bastard).

https://www.reddit.com/r/linusrants [!!! WARNING !!! Strong Language]

 

Introduction: Advantages of Git

● Fast

With a full clone of the repo, nearly all operations are local.

milliseconds vs. tens-of-seconds (e.g. opening a file, viewing history, viewing diffs).

● Free

Commercial solutions are NOT cheap (e.g. Perforce, Clearcase, etc). Maintenance,

upgrades, licensing add up. Git is maintained by a large open-source community

(1000+ contributors).

● Flexible Workflows

Customizable workflows (centralized, dictator/lieutenant, etc)

Pull model popular (e.g. open-source community). Encourages code reviews and

promotes trust.

● Lightweight Branching & Merging

Software development relies heavily on branching. So having a lightweight branching

scheme is very useful.

● Inherent Data Redundancy / Replication

Every clone is a fully-replicated repo.

File corruption easily identifiable since GIT performs SHA1 hashes on content.

 

Introduction: Advantages of Git

● Centralized vs Distributed

Centralized Model

Cons

● Slow, single bottleneck

● Requires constant connectivity to repo

● Difficult for remotely distant users

Distributed Model

Pros

● Extremely Fast

● Local / Offline Access

● Inherent Data Replication / Redundancy

 

Getting Started: Installing Git

● Linux Install

◆ Fedora: dnf install git-all (older distros: yum install git-all)

◆ Debian: apt-get install git-all

● MAC OSX Install:

http://git-scm.com/download/mac

● Windows Install:

https://git-scm.com/download/win

● Compile from Source (configure, make, make install):

https://www.kernel.org/pub/software/scm/git

 

Getting Started: Git Configuration

● User-Identity Commands:

git config --global user.name

git config --global user.email

● Both used to identify commits

git config --global user.name "Anand G"

git config --global user.email anandg@google.com

[anand anandg@ /home/anandg (master)]$ git show 8g91

commit 8d91ec397bce6f5441c2ce25178ed5aa99d2d456

Author: Anand G anandg@google.com

Date: Wed July 3 13:48:47 2019 -0530

Test commit

● Viewing Config:

git config -l

 

Getting Started: Creating a Repo

● Command:

git init [--bare]

● Typically not needed since we often rely on existing repository

managers (e.g. GitLab, GitHub, Gerrit, etc).

● A bare repository does not contain a working directory tree

(i.e. no local files can be committed).

● Bare repositories are used as centralized servers to synchronize work

among multiple users.

● By convention, repos ending with .git indicate bare repos

( e.g. git clone git@github:testrepo.git ).