Difference between revisions of "Version Control"

From eLinux.org
Jump to: navigation, search
(Why use it)
(Updated with changes by @matthewmccull)
Line 1: Line 1:
 +
=NB This page is currently being developed at https://github.com/alecthegeek/version-control-basics. Please fork at send me a pull request=
 +
 
=Justification=
 
=Justification=
  
Line 7: Line 9:
  
 
# Able to describe the benefits of using version control
 
# Able to describe the benefits of using version control
 +
## Describe problems that can occur when groups of people work together on computer files over time
 +
## Understand basic VC terminology -- commit, commit hisory, change, branch, merge, commit message
 
# Can use Git for version control of new and existing projects, including working in a group
 
# Can use Git for version control of new and existing projects, including working in a group
 
## Create a local repository (repo)
 
## Create a local repository (repo)
## Commit a change
+
## Commit a change or modification
 
## Create a branch
 
## Create a branch
 
## Show the history
 
## Show the history
## Show change differences
+
## Show change differences using diff
## Perform a local merge
+
## Perform a merge
## Push and pull changes to a remote repo
+
## Push and fetch changes to and from a remote repo (optional use of pull command)
  
 
=Introduction=
 
=Introduction=
Line 47: Line 51:
 
#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)
 
#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
 
#:Individual developers find this information useful as part of their daily an it also helps organisations with their compliance and audit management
#Undo a half complete change made in error and "roll back" to a previous version
+
#Undo a half complete or incorrect change made in error and "roll back" to a previous version
 
#Recreate the system as it was at some point in the past
 
#Recreate the system as it was at some point in the past
  
Line 114: Line 118:
  
 
We can ignore most of the detail for now. What important is that Git:
 
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
+
# Warns us that some files are not being controlled (untracked) by the VCS
 
# Lists the files and directories with their status. We will see this change as we progress further in the example.
 
# Lists the files and directories with their status. We will see this change as we progress further in the example.
  
Line 131: Line 135:
  
 
=External References=
 
=External References=
 +
 +
 +
-Several videos that introduce the basic ideas of version control can be found at http://git-scm.com/videos or on YouTube at:
 +
 +
 +
-* Episode 1: http://www.youtube.com/watch?v=K2wBGt-j0fE
 +
-* Episode 2: http://www.youtube.com/watch?v=0BIGxolZQHo
 +
-* Episode 3: http://www.youtube.com/watch?v=ojVzmIp6Xv0
 +
-* Episode 4: http://www.youtube.com/watch?v=pv25aLwYpEU
  
 
* [http://progit.org/ Pro Git], an online and published book
 
* [http://progit.org/ Pro Git], an online and published book
 
* [http://youtu.be/ZDR433b0HJY Introduction to Git] video with Scott Chacon of GitHub
 
* [http://youtu.be/ZDR433b0HJY Introduction to Git] video with Scott Chacon of GitHub

Revision as of 21:13, 11 May 2012

NB This page is currently being developed at https://github.com/alecthegeek/version-control-basics. Please fork at send me a pull request

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
    1. Describe problems that can occur when groups of people work together on computer files over time
    2. Understand basic VC terminology -- commit, commit hisory, change, branch, merge, commit message
  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 or modification
    3. Create a branch
    4. Show the history
    5. Show change differences using diff
    6. Perform a merge
    7. Push and fetch changes to and from a remote repo (optional use of pull command)

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

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:

  1. Two people might be editing the same file at once and changes can be overwritten
  2. 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:

  1. 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.
  2. TODO

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 half complete or incorrect 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 the Raspberry Pi website 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 some files are not being controlled (untracked) by the 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

-Several videos that introduce the basic ideas of version control can be found at http://git-scm.com/videos or on YouTube at:


-* Episode 1: http://www.youtube.com/watch?v=K2wBGt-j0fE -* Episode 2: http://www.youtube.com/watch?v=0BIGxolZQHo -* Episode 3: http://www.youtube.com/watch?v=ojVzmIp6Xv0 -* Episode 4: http://www.youtube.com/watch?v=pv25aLwYpEU