Difference between revisions of "Version Control"

From eLinux.org
Jump to: navigation, search
m (Outcomes)
m (Encouraging people to adapt the material)
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=Justification=
+
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
 
  
=Outcomes=
+
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 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
 
 
 
=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, for example fix a bug in our project, is completed the developer decides a logical 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==
 
There are three core things a VCS helps do
 
#Answer the 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 I've made in error and "roll back" to start again
 
#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.
 
 
 
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 tying 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 teh 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
 

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.