Version Control
Agile Development
Content
Introduction
Local version control
Remote repositories
Team collaboration with Git
Branching
Version Control
Common Coding Problems
Where is my code / it's on a different computer
What has changed and when?
I’ve broken my program and can’t fix it
I need to work on a different computer
Just Remind
My team members are all working on the same file!
Who has modified the files and when?
Who has been doing to the programming?
Revision Control Systems Exam Question
The management of changes to documents
Each changes are usually identified by a revision number
Each revision has a timestamp and the person responsible
Revisions can be compared, restored, and merged
Need to remember
Purpose
Stores snapshots of a project:
Complete history Need to remember
Can 'rewind' to earlier versions
Can store a copy of a project online (backup)
Allows controlled access by all team members
Control version release
Track issues
Store documentation
Key Features
Backup and Restore (rollback)
Synchronization between developers
Need to remember
Short-term undo (last-known good)
Long-term undo (jump to old version)
Track Changes (to see file evolution)
Track Ownership (blamestorming)
Sandboxing (isolate potentially damaging changes)
Why Use Version Control?
Its very easy to set up and run
Full tracking and audit of project files
All software development companies require employees to use version control
Why would you not use it?
Takeaway
Version control systems allow developers to capture snapshots of their code and
allow it to be audited and rolled back
It also allows code to be simultaneously developed by multiple developers and
teams
It is good practice to always use version control when programming
Local Version Control
What is Git?
Git is a version control system
It can help you keep track of files that are frequently changed
it supports distributed development
It's Open Source (you can download and install it for free)
Need to remember
Git Local Workflow
git checkout Complete record
of all commits
add
new files
Working
Repository
Files
Available for
editing
git add git commit
Staged Files
A group of changes
to be added
What is a Git Repository?
A hidden directory in the project directory
Contains a complete record of all changes (commits)
Can generate a set of working files (checkout)
Each change is recorded with the originator and date/time
We can add a repository to any directory containing code
Git Settings
There are a number of important Git settings stored on the development
computer:
Developer's name
Registered email address
Preferred editor
These can be stored:
globally (affect all repositories on the workstation)
Locally (in a specific local repository)
Creating a Git Repository
Git repositories can be created in any directory on a computer
Creates a special hidden .git/ directory that is used to track changes
Repository Status
The repository status shows:
Any files that are not being tracked
Any files that have been modified but not staged
Any files that have been staged but not yet committed
Staging Files and Committing
Modified files are added to a staging area
All the files in the staging area are:
Flagged with a message describing the changes
Changes are then added to the local repository (committed)
Commits also contain:
Details of the person committing the changes
A timestamp
How is the Data Stored?
Each commit creates a snapshot of the files
Each snapshot is given a hash (short and long versions).
The active branch pointer is indicated by the HEAD pointer.
The active branch pointer moves to the new commit.
This pointer can be moved to any previous commit.
The checkout command works on the commit pointed to by the HEAD pointer.
Ignoring Files
Some files don’t need to be included in your repository
binaries
third-party libraries
We can create a special hidden .gitignore file
Contains a list of files to ignore
What Should be Included?
Include Exclude
Source Code Editor and IDE settings
System Configuration Files Build files
Scripts to Build Databases Binary executables
Test Suites 3rd party libraries
Just Remind
Sample .gitignore File
# Comment #
###########
*.com
modules/
temp.md
Branch Head
HEAD
MASTER
Branch Head After 1 Commit
HEAD
MASTER
Branch Head After 2 Commits
HEAD
MASTER
Takeaway
The Git versioning tool can be used to track changes to locally stored code
Changes to groups of modified files are stored and each set of changes includes a
description
Remote Repositories
Watch Recordings
Remote Repositories
Versions of your project hosted on the Internet / network.
Your repository can point to many of these.
Each remote is either read-only or read/write.
Collaborating with others means managing these.
Allowing developers to take working copies of them (clone)
Pushing and pulling data to and from them.
Git Remote Workflow
Complete record git push
git checkout of all commits
add
Repository
new
files Working
Repository
Files
git pull
Available
for editing
git add git commit
Staged
Files
A group of changes
to be added
Creating a Remote Repository
This needs to be created on the remote host (GitHub, GitLab or equivalent)
Must create a blank repository (no files)
Each repository has a unique URL
This will be used to connect to the local repository
Adding a Remote Repository
When adding a remote repository:
You need the remote url
You need to give it a name (default is origin )
Pushing to a Remote / Pulling
Once the remote has been added to the local repository
All the local commits can be pushed to this remote
Any commits that are on the remote but not locally can be pulled
Takeaway
Remote repositories allow for local code to be stored and backed up online
The remote is a complete copy of the local repository including all commits
Local commits can be pushed to the remote
Remote commits can be pulled into the local repository
Team Collaboration with Git
Sharing Code
Each member of the team clones a copy of the remote
Changes and commits are made locally
Two Scenarios:
Commits have been pushed that are not in your local repository
Two developers modify the same file
Git Clone
HEAD
origin ALICE
A B
HEAD
A B
BOB HEAD
A B
Git Commit
HEAD
origin ALICE
C
A B 1
HEAD
A B
BOB HEAD
C
A B 2
Git Push (Alice)
HEAD
origin ALICE
C
A B 1
HEAD
C
A B
1
BOB HEAD
C
A B 2
Git Push (Bob)
HEAD
origin ALICE
HEAD
C
A B 1
HEAD C
1
A B
HEAD
BOB HEAD
C
2 C
A B 2
push rejected (HEAD is 1 commit forward)
Merge Conflict (Bob)
origin
HEAD
C
A B D
1
C
2
Takeaway
Branching
Watch Recordings
What is a Branch?
A lightweight pointer to a commit
Each repository must have at least one branch
By default it's called master
HEAD
The HEAD pointer points to a branch pointer MASTER
Branching
Master Branch contains stable code…
How do we test unstable changes?
Create a new branch
Example: fix-53-login
Types of Branch
Three types of branch:
Local only exists in the local repo (not pushed)
Remote only exists on the remote repo (not locally)
Tracking is where a local branch is linked to a remote
Creating a New Branch
This simply adds a new lightweight pointer to the currently checked out commit.
Switching to the new branch moves the HEAD pointer to the new branch pointer.
MASTER
LOGIN
HEAD
Committing to the New Branch
Commits are chained to the commit addressed by the branch addressed by the
HEAD pointer.
MASTER
LOGIN
HEAD
After the Commit...
Once the commit is made the pointer addressed by the HEAD pointer is moved to
the latest commit.
All the other branch pointers remain.
MASTER
LOGIN
HEAD
Pushing a Second Commit
This process is repeated for each commit.
MASTER
LOGIN
HEAD
Switching Branches
Switching to another existing branch moves the HEAD
This now points to the branch we switched to.
HEAD
MASTER
LOGIN
Committing to a Second Branch
As before, the new commit is chained to the HEAD
commit addressed by the HEAD pointer.
MASTER
The branch and HEAD are moved.
LOGIN
Merging a Branch
Process of pulling branch changes into another branch
Typically we merge back into the master branch
Once done we can delete the extra branch.
Merging a Branch
LOGIN
HEAD
MASTER
Takeaway
Branches are used to develop new features or fix bugs
This keeps the code away from the main product code until it is completed
Working code is merged back into the stable (master) branch
Further Reading
