Difference between revisions of "Version Control"

From eLinux.org
Jump to: navigation, search
(Introduction: Added some justification)
m (Encouraging people to adapt the material)
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
This material is published at http://alecthegeek.github.com/version-control-basics/
# VC is an important skill for developers and a prerequisite for developing quality software
# DVCS will provide a useful platform for students to work together on projects
It is developed at https://github.com/alecthegeek/version-control-basics. Please fork and send a pull request. The material is distributed under a free content. Please adapt the material for your own needs.
# Able to describe the benefits of using version control
# Can use Git for version control of new and existing projects, including working in a group
## Create a local repository (repo)
## Commit a change
## Create a branch
## Show the history
## Show change differences
## Perform a local merge
## Push and pull changes to a remote repo
==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 [http://en.wikipedia.org/wiki/Revision_control Revision Control]
==Why use it==
Imagine a software project. It might have hundreds of files (for example source code, build scripts, graphics, design documents, plans etc) and dozens of people working on the project making
different types of changes. There are severael problems that will happen:
# Two people might be editing the same file at once and changes can be overwritten
# After the project has been running for some time it's very hard to understand how the project has evolved and what changes have been made.
There are additional problems as well:
# How can we locate a problem that might have been introduced some time ago. Just fixing the problem may not be enough, we probably also need to to understand the change that introduced it.
There are three core things a VCS helps do
#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
#Undo a change made in error and "roll back" to a previous version
#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 [http://www.raspberrypi.org/game.tar.gz] into a directory called <code>snakes</code>.
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
# Make sure you have the correct tools installed by typing the following commands:
  sudo apt-get install git git-gui git-gitk
# Test the installation with the command
  git --version
#: 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 <code>.git</code>. 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>code init</code> or <code>code status</code>. 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:
# Warns us that there some files that are not being controlled by the VCS
# 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=
* [http://progit.org/ Pro Git], an online and published book
* [http://youtu.be/ZDR433b0HJY Introduction to Git] video with Scott Chacon of GitHub

Latest revision as of 15:52, 27 May 2012

This material is published at http://alecthegeek.github.com/version-control-basics/

It is developed at https://github.com/alecthegeek/version-control-basics. Please fork and send a pull request. The material is distributed under a free content. Please adapt the material for your own needs.