Title Text

OTher Concepts And Tools

VERSION CONTROL SYSTEMS

WITHOUT Version Control

Without a way to track the changes in our code, a few issues take form:

What is the latest version?
New features introduced errors. What now?
Two developers working on the same code. How do they merge their work? How do they prevent conflicting alterations?
Local machine dies. What happens to the work?

WITH VERSION CONTROL

Version control is the practice of tracking and managing changes to software code.

Version Control Systems are Software tools that help software teams manage changes to source code over time.

BENEFITS OF VERSION CONTROL

Complete, long-term change history of every file - includes creation and deletion of files, as well as edits to their contents.

Branching and merging - creating a "branch" in VCS tools keeps multiple work streams independent from each other while providing the facility to combine that work back together.

Traceability - tracing each change, annotating it with a message that describes its purpose and intent, and connecting it to project management and bug tracking software, can help with root cause analysis and other forensics.

TYPES OF VERSION CONTROL

Local VCS

A simple database that keeps all the changes to files under revision control.

TYPES OF VERSION CONTROL

Centralised VCS

A single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.

TYPES OF VERSION CONTROL

Distributed VCS

Clients don't just check out the files' latest snapshot; they fully mirror the repository, including its entire history.

If any server dies, any client repository can be copied back up to the server to restore it. Every clone is a full backup of all the data.

GIT BASICS

A Little History

Linux Kernel is an open source software project, with thousands of collaborators.

1991-2002 changes were passed around as archived files

2002 - started using BitKeeper (proprietary)

2005 - BitKeeper's free-of-charge policy revoked; Linus and the community decided to develop their own tool

GIT

Speed

Simple design

Strong support for non-linear development

Fully distributed

Capacity to handle large projects efficiently

GIT

GIT SETUP

After installing git in your machine, you'll want to do a few things to customise your git environment.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
$ git config --global core.editor vim
$ git config --list
$ git help <verb>

Check this link for a VIM tutorial.

Live coding

Creating and using a Git repository

Live coding

Cloning a Git repository

Live coding

Viewing the commit history

Live coding

Undoing work on Git repository

Live coding

Working with remote repositories

GIT BRANCHING

Branching in Version control Systems

Branching refers to the creation of a new line of development, separate from the main line.

This can be used to work on a new bug fix or feature without affecting the main line in the process.

Compared to other VCSs, Git has a branching model that is quite lightweight, as branches are movable pointers, which are moved as new commits are created.

Creating Branches

By default, repositories have a "master" branch - now more commonly called "main" branch". This is created automatically with the git init command.

In order to create a new branch, the git branch <branch-name> command can be used. It will create a new branch, which will point at the commit of the current branch.

At this point, we will have two branches pointing at the same commit. How do we know and change in which branch we are working on?

Creating Branches

The HEAD file is a reference to the current branch. When a new branch is created with the command git branch <branch-name> the HEAD remains in the previous branch.

Changing between Branches

The git checkout <branch-name> command allows for switching between pre-existing branches.

It is also possible to create and automatically change to a new branch with git checkout -b <branch-name>

Live coding

Git branches: basic example

Other Branch Functionalities

The git branch command can be used for other functions:

git branch or git branch --list provides a list of existing branches

git branch -d <branch-name> deletes a branch

git branch -m <branch-name> renames the current branch

git branch -m <old-name> <new-name> renames another branch

Managing REmote Branches

The previous commands work with branches at a local level.

In order to apply these changes to the remote repository, we must push the changes:

git push <remote-alias> <branch-name> pushes a copy of the branch to the remote repo URL, saved in the remote alias (the alias is commonly origin)

In order to rename a remote branch, the process is a bit different. After renaming the local branch:

delete the old remote branch
push the renamed local branch again.

Managing REmote Branches

In order to delete a remote branch:

git push <remote-repo> --delete <branch-name>

This action does not affect the local branches associated with the deleted branch of other people. They can create a new remote branch, or recreate the same using push.

Managing remote branches can also be performed in the browser.

Live coding

Git branches: local and remote management

GIT Merge

Merging branches

Once we have finished the work of a specific branch, we will want to bring the new changes to the main line (or to another branch), by merging them.

Specifically, a target branch is merged into the current branch, by finding a common base commit and combining the changes into a new merge commit.

Merging branches

Unlike others, merge commits have two parent commits.

Before performing a merge, it is important to check if:

- We are at the branch that will receive the merge

- There are no "uncommited" changes

- Both the receiving and merging branches are up-to-date

After these checks, the merge can be performed, using the command git merge <merging-branch>

What happens if each branch has different changes in the same part of a file?

Merge Conflicts

In these cases, Git identifies the merge conflicts, which must be resolved before creating the merge commit.

The files with merge conflicts can be checked with git status, and can then be solved with any editor or Git GUI (or even in the Git bash).

The sections with merge conflicts are identified as follows:

This is our text file.
<<<<<<< main
This was the 2nd line, on the receiving branch.
=======
This was the 2nd line, on the merging branch.
>>>>>>> feature branch
This is the third line, no changes here.

Content of a simple .txt file, where the second line was different in both branches.

Merge Conflicts

To solve the conflicts, the files in question must be updated in order to contain the changes of either or both branches.

The undesired changes (and the symbols used for the merge conflicts) must be removed.

After all conflicts are solved, the merge commit is created as any other commit, by using git add to add the now-solved files and then git commit.

This is our text file.
This was the 2nd line, on the merging branch.
This is the third line, no changes here.

Content of the simple .txt file, where we kept the changes from the merging branch.

Live coding

Git branches: merging