Version Control

From eLinux.org
Revision as of 16:42, 28 April 2012 by Alecthegeek (talk | contribs) (Added some reference material)
Jump to: navigation, search

Justification

  1. VC is an important skill for developers and a prerequisite for developing quality software
  2. DVCS will provide a useful platform for students to work together on projects

Outcomes

  1. Able to describe the benefits of using version control
  2. Can use Git for version control of new and existing projects, including working in a group
    1. Create a local repository (repo)
    2. Commit a change
    3. Create a branch
    4. Show the history
    5. Show change differences
    6. Perform a local merge
    7. Push and pull changes to a remote repo

Introduction

What is Version Control and how do Version Control Systems work?

Version Control (VC) is a common practice used to track all the changes that occur to the files in a project over time. It needs a Version Control System (VCS) tool to work.

The way that a VCS works by recording a history of changes. What does that mean?

Every time a change is completed (for example fixing a bug in a project) the developer decides a logical "save" point has been reached and will store all the file changes that make up the fix in the VCS database. The term often used for a group or changes that belong together like this is a changeset. As well as changing lines of code in source files there might be changes to configuration files, documentation, graphic files and so on. Along with the changes to the files the developer will be prompted by the VCS to provide a description of the change with a commit message which is appended to the commit log. The process of storing the changes in the VCS database (usually refereed to as the repository or repo for short) is called making a commit.

The hard work in making a commit is done by the VCS, all the developer does is issue the commit command and provide the commit message. The VCS software calculates which files have changed since the last commit and what has changed. It then stores these changes, plus the commit message, the date, time, name of the developer (committer), commit message and other information in the repository.


Version Control is also sometimes refereed to as Revision Control

Why use it

There are three core things a VCS helps do

  1. Answer the following questions: "What changes were made in the past?", "Why were they made?" and "Who made them?" (via commit history and commit comments)
    Individual developers find this information useful as part of their daily an it also helps organisations with their compliance and audit management
  2. Undo a change made in error and "roll back" to a previous version
  3. Recreate the system as it was at some point in the past

Tools available

  • Distributed vs. Centralised
    Modern VCS work on a distributed model (DVCS). This means that every member of the project team keeps a complete local copy of all the changes. The previous model, still widely used with tools like Subversion, is centralised. There is only one central database with all the changes and team members only have a copy of the change they are currently working on.
  • Open Source and Commercial Tools
  • What the tools do
    • Commit history
    • Diff listing
    • Integrate with other tools (e.g. Ticket Systems, built Systems, project management etc)

An example using Git

Git is vey popular DVCS originally developed to maintain the GNU/Linux kernel source code (the operating system that usually runs on the Raspberry Pi). It is now used by many very large open source projects and a lot of commercial development teams. Git is very flexible and has a reputation of being hard to use, but we are only going to concentrate on the ten or so commands you need to be useful day to day.

There are many excellent tutorials for Git on the Internet. See the External References section below.

These examples assume that you are using Debian Linux on a Raspberry Pi and have downloaded the Python Snakes project from [1] into a directory called snakes. All the commands are issued from a terminal. You can start the terminal from the LXDE GUI by #TODO..... Initially this example assumes that the current directory is your home directory, which is the default when you start a terminal window.

  • Setup up
  1. Make sure you have the correct tools installed by typing the following commands:
  sudo apt-get install git git-gui git-gitk
  1. Test the installation with the command
 git --version
  1. you should see something like
 git version 1.7.10

Tell Git who you are (this is very important information and it recorded in every change in you make or commit)

 git config --global user.name "My Name"
 git config --global user.email "myname@mycollege.ed.uk"

You should of course substitude your own name and email address in the correct places. Git records that information is a use configuration file called .gitconfig in your home directory

  • Creating a repo

The next thing we need to do it create an empty Git database, called a repo (short for repository) inside our snakes directory

 cd snakes
 git init
 Initialized empty Git repository in /home/alec/snakes/.git/

Notice that the VC tool has created a hidden directory called .git. In Linux all file and directory (folder) names that start with a "." are normally hidden

Next we issue a status command.

 git status

In Git all commands are typed after the word git (e.g. code init or code status. The output from the status command is

 # On branch master
 # 
 # Initial commit
 #
 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #	game/
 #	helloworld.py
 #	if.py
 #	maths.py
 #	variables.py
 #	while.py
 nothing added to commit but untracked files present (use "git add" to track)

We can ignore most of the detail for now. What important is that Git:

  1. Warns us that there some files that are not being controlled by teh VCS
  2. Lists the files and directories with their status. We will see this change as we progress further in the example.
  • Committing a file
  • Making a change
  • Showing the diff
  • Committing the change
  • Showing the history
  • Branches

Working with others

  • Remote repos
  • Merging
  • Patches

External References