1 of 38

3 - Version Control System.

Speck Academy 2021

2 of 38

About VCS

Categories of VCS

GIT basics

GIT branching

GIT merging

Gitflow workflow

1

2

3

4

5

6

Overview

3 of 38

1

About VCS

4 of 38

About VCS

Version Control System - VCS

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

By using version control systems, unlimited number of developers can work on the same code base.

VCS allows you to:

  • Revert selected files or entire project to a previous state
  • Compare changes over time
  • See last modified files that might be causing problem

5 of 38

2

Categories of VCS

6 of 38

Categories of VCS

Centralized Version Control Systems - single server that contains all the versioned files, and a number of clients that check out files from that central place.

Distributed Version Control System - Compared to CVCs, clients don’t just check out latest snapshot of the files, rather, they fully mirror the repository, including its full history.

  • 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.

7 of 38

Categories of VCS

Repository

Working copy

Working copy

Centralized VCS

Workstation #1

Workstation #2

Commit / Update

Repository

Repository

Repository

Distributed VCS

Push / Pull

Commit / Update

Working copy

Workstation #1

Working copy

Workstation #2

8 of 38

Advantages of DVCS

Performing actions other than pushing and pulling changesets is extremely fast because the tool only needs to access the hard drive, not a remote server.

Commiting new changesets can be done locally without anyone else seeing them. Once you have a group of changesets ready, you can push all of them at once.

9 of 38

3

GIT basics

10 of 38

GIT basics overview

Jargon

History

About GIT

GIT snapshots

The three states

Essential commands

11 of 38

Jargon

In order to understand GIT we will use some specific terms:

  • Repository (repo) - database where files are stored
  • Server - the computer storing the repository
  • Client - the computer connecting to the repository
  • Working copy - your local directory of files
  • HEAD - the latest revision in the repository
  • Add - place a file under version control
  • Diff - specific modification to a document
  • Branch - duplicate copy of code used for feature development
  • Merge - integrate changes from two different branches
  • Resolve - manual fixing of conflicted document changes

12 of 38

History

Created by Linux development community in 2005 after the collaboration of the Linux community with BitKeeper was broken.

Some of the Goals:

  • Speed
  • Simple design
  • Strong support for non-linear development (thousands of parallel branches)
  • Fully distributed
  • Able to handle large projects

13 of 38

About GIT

GIT is most widely used modern version control system in the world.

Major difference between GIT and any other VCS is the way GIT thinks about its data.

The others systems (CVS, Subversion, Bazaar...) think of the information they store as a set of files and the changes made to each file over time (delta-based version control).

GIT thinks of its data more like a series of snapshots of a miniature filesystem.

14 of 38

Essential commands

List of essential commands:

  • git config --global user.name ‘’Username”
  • git config --global user.email ‘’example@example.com
  • git help
  • git init
  • git clone
  • git add
  • git commit
  • git diff
  • git reset

More about undoing changes

15 of 38

GIT snapshots

Version 1

A

B

C

Version 2

A1

B

C1

Version 3

A1

B

C2

Version 4

A2

B1

C2

Version 5

A2

B2

C3

16 of 38

GIT snapshots

What is actually happening?

Each time we run git commit, new snapshot of whole filesystem is being created.

After that, GIT automatically creates packfile whose content is compressed and delta encoded.

So in fact, GIT also saves diffs to files but the way it does it’s different from other VCS.

17 of 38

The three states

Modified means that you have changed the file but have not committed it to your database yet.

Staged means that you have marked a modified file in its current version to go to your next commit snapshot.

Commited means that the data is safely stored in your local database.

18 of 38

The three states / Modified

Git directory (repository)

Working directory

Staging area

You modify files in your working directory.

19 of 38

The three states / Staged

Git directory (repository)

Working directory

Staging area

You stage the files, adding snapshots of them to your staging area.

Stage files

20 of 38

The three states / Committed

Git directory (repository)

Working directory

Staging area

You do a commit that stores snapshot permanently to your Git directory.

commit

stage files

21 of 38

The three states / Checkout

Git directory (repository)

Working directory

Staging area

You do a commit that stores snapshot permanently to your Git directory.

stage files

Checkout the project

commit

22 of 38

4

GIT branching

23 of 38

GIT branching

Branching means you diverge from the main line of development and continue to do work without messing with that main line.

Branches are used to develop features isolated from each other.

The way GIT branches is incredibly lightweight, making branching operations nearly instantaneous, and switching back and forth between branches generally just as fast.

Default branch is master.

A branch is not available to others unless you push the branch to your remote repository.

24 of 38

GIT branching

Useful commands:

  • Show all the branches - git branch
  • Creates new branch - git branch new_branch_name
  • Switch to a different branch - git checkout other_branch_name
  • Creates a new branch and switches to it - git checkout -b new_branch_name
  • Push branch to your remote repository - git push origin branch_name
  • Delete a branch - git branch -d branch_name

Origin is a default name given to the original remote repository that you clone, from where you want to pull and push changes.

25 of 38

5

GIT merging

26 of 38

GIT merging 1/3

In order to explain merging try to understand following scenario:

  1. You are on a master branch and PM told you that you need to implement new feature for current application. In order to do that, you need to create new feature branch - git checkout -b feature/new-feature.
  2. After you made some changes in feature branch, PM told you that you need to make hotfix on master branch. In order to do that, you need to return to master branch and from there create a new hotfix branch.
  3. After you have created hotfix branch and fixed some things in code, you need to merge changes to master:
    • git checkout master
    • git merge hotfix

27 of 38

GIT merging 2/3

  1. Now it’s time to return to feature branch and continue with implementation of new feature. If feature is implemented then checkout to master and merge feature branch to master - git merge feature/new-feature

What just happened?

  • Three-way merge, which means that commit on the branch you’re on isn’t direct ancestor of the branch you are merging in. This is normal because previously you did some work on hotfix and current master branch and master branch from which feature branch is created have diverged. If feature and hotfix branch didn’t changed the same part of code, then merge is executed without conflict.

28 of 38

GIT merging 3/3

Merge conflict:

  • Let’s consider 4th step from previous slide and say that hotfix and feature branch did changes on the same part of code.
  • In this case there will be merge conflict which prevents merge to be executed, to resolve this you’ll need to decide which changes will be accepted and run git commit manually to finish merging.
  • Merge conflict is possible only in Three-way merge.
  • Read more about merging

29 of 38

6

Gitflow workflow

30 of 38

Gitflow workflow

The Gitflow workflow defines a strict branching model designed around the project release.

The overall flow:

  1. A develop branch is created from master
  2. A release branch is created from develop
  3. Feature branches are created from develop
  4. When feature is complete it is merged into the develop branch
  5. When the release branch is done it is merged into develop and master
  6. If an issue in master is detected a hotfix branch is created from master
  7. Once the hotfix is complete it is merged to both develop and master

31 of 38

Gitflow workflow / master & develop

The master branch stores the official release history, and the develop branch serves as an integration branch for features.

Master

Develop

v0.1

v0.2

v1.0

32 of 38

Gitflow workflow / feature

Each new feature should reside in its own branch. Feature branches use develop as their parent branch.

Master

Develop

v0.1

v0.2

v1.0

Feature

Feature

33 of 38

Gitflow workflow / release

Created once develop has acquired enough features for release. No new features can be added after this point, except bug fixes and documentation.

Master

Develop

v0.1

v0.2

v1.0

Feature

Feature

Release

34 of 38

Gitflow workflow / hotfix

Maintenance or hotfix branches are used to quickly patch production releases.

Master

Develop

v0.1

v0.2

v1.0

Feature

Feature

Hotfix

Release

35 of 38

7

Hands-on

36 of 38

Hands-on

37 of 38

8

Homework

38 of 38

Homework