CSC/ECE 517 Fall 2013/ch1 1w6 zs

CSC/ECE 517 Fall 2013/ch1w6 zs

Synopsis of Git book

Introduction

Git is by far the best Version Control System on the market and it's free.

Version Control System

Version control system is a system that keeps track of changes to a set of files for a certain project. You can recall all specific versions of your file later. Actually any file on your computer is placed under version control. A VCS allows you to revert file to a previous version or even revert the whole project back to a certain version. It allows you to see what when changes are made and who modified it. It also allows you to recover yourself easily from a messed up project.

Generally, there are three kinds of version control system, which are local, centralized and distributed VCSs. Figures are illustrated below. Local Version Control

Centralized Version Control System

Distributed Version Control System

History

Git was born with a bit of creative destruction and fiery controversy. The linux kernel , which is an open-source software project, kept its changes as patches and archived files from 1991 to 2002 and since 2002. The project switched to a Distributed VCS called BitKeeper.

When things between the community that developed linux kernel and the commercial company that developed Bitkeeper went bad. The free version of the BitKeeper was revoked and this prompt the community that developed Linux kernel to develop their own tools. And that is the origin of Git.

For over 7 years since its birth in 2005, Git has matured and it’s now handy to use while keeping the good qualities. It's especially efficient for large projects and it has a amazing branching system(another link here for branching ) for non-linear development .

What is Git

Git stores ,process and thinks about information in a different way than any other VCS. Systems like CVS deals with the information they hold as a set of files and changes made to each single file over time. But Git doesn't do it this way.Git takes your file more like a series of snapshots. Every time you commit or save your file, Git takes a snapshot of all your files. And to avoid unnecessary memory consumption , those files that stay unchanged are stored as a link to its previous real version. Illustrated as below.

Git's Snapshots way of thinking data

This is a huge difference between Git and other VCSs, actually nearly all other VCSs. Git take care of very aspect of version control at a minimum cost.It's more like a set of mini file system with lots of advanced tools built in.

Most operation in Git is local and no data or information is needed on another computer. You always have an entire history of your project on your local computer. It's so efficient that most operations seems instant. That means you can browse your entire project history on you local database almost instantaneous. Git can look up a file no matter how long ago and compare it with your current version with diff calculation.When you are offline , you can easily make changes to your projects and commit the change once you are connected to the internet. Besides that, if you are off VPN, you can still work. Although it seems trivial, this will make a huge difference.

Everything you do on Git is known to Git. You won't lose lose anything or get file corruption before Git detecting it. This is done by adopting checksumming using SHA-1 hash. It's a 40 character string composed of hex characters. Git stores everything in the Git database addressable by the hash value of its contents, other than file name.

Generally Git only adds data to Git database. After committing a snapshot into Git database, it's very hard to lose data. This is especially secured if you regularly push Git database into another repo.

Important: Git has three states for a file to reside in, which are committed, staged and modified.Committed means that your file is safe and sound in Git database. Modified means that you have changed the file but it's not committed into database yet.Staged means that you mark a modified file in its current version and ready for the next snapshots. It's like cache. The three states and their connection is illustrated in the figure below.

The repo is where Git stores data for your project.When you clone a repo from another computer, this is the thing copied. The working directory is a simple check out for your current version of files.The files on working directory are pulled out of repo and put on disk for you to manipulate. The staging area is a simple file which is contained in repo. It stores information that will go into the commit stage.

Generally, the follow three steps are how Git works:

1.You modify files in your working directory.

2.You stage the files, adding snapshots of them to your staging area.

3.You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Getting Started on Git

Installing Git

First thing to use Git is to install it. You can either install it from sources or installing package on your platform(Win, Mac and Linux)

Install from Source

One of the advantage of installing from source is you always get the latest version. Each version of Git tend to add some UI enhancement and it will be comfy to compile on that. To start with, there are some must-have libraries that Git depends on, such as curl, zlib, openssl, expat and libiconv.If your system has yum (such as Fedora) or apt-get (such as a Debian based system), then you can use the one of the commands below to install the all the dependencies.

$ yum install curl-devel expat-devel gettext-devel \
 openssl-devel zlib-devel

$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 libz-dev libssl-dev

Once this is done, you can go ahead and download the latest version of Git

 http://git-scm.com/download

And then, compile and install

$ tar -zxf git-1.7.2.2.tar.gz
$ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install

After this is done, Git is already installed on your local computer. You can use the following command to update your Git to latest version.

$ git clone git://git.kernel.org/pub/scm/git/git.git

Install on Linux

It's way much easier to install Git on Linux. If you are on Fedora, you can use the following yum

$ yum install git-core

If you are on a Debian-based distribution like Ubuntu, use apt-get

$ apt-get install git

Install on Windows

Suprisingly,it's very east to install Git on Windows. Download the Git installer exe file from Github page and run it.

http://msysgit.github.com/

After installing on windows, you will have both command-line and GUI version.It is suggested that windows users to use msysGit shell, which supports many complex commands.

First time set-up

You may want to customize your Git environment once and for all. It will persist after each upgrade and you can also make changes to your settings using the commands again.

A tool called git config is built in on Git , it allows you to get and set configs that control all things about how Git looks and runs.The config variables are stored in three different places:

1. /etc/gitconfig file: Contains values for every user on the system and all their repositories. If you pass the option --system to git config, it reads and writes from this file specifically.

2. ~/.gitconfig file: Specific to your user. You can make Git read and write to this file specifically by passing the --global option.

3. config file in the git directory (that is, .git/config) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in .git/config trump those in /etc/gitconfig.

Identity, Editor, Diff tool and Check

You should set your user name and email address once you get your Git installed. Every Git commits uses this info and it's etched in your commits.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Because you passed the --global option, you only need to do this once.

You can config your default editor when Git asks you to type any message. If you want to use another editor other than your system's default editor like emacs, you can use the following command. Usually it's Vi or Vim by default.

$ git config --global core.editor emacs

You will want to use diff tools for detecting and resolving emerge conflicts.There are many diff tools and let's assume you want to use vimdiff, you should type the following command

$ git config --global merge.tool vimdiff

Git also accept kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools.

If you want to check your settings, Git has provided a --list option for you to view all your settings. By typing "git config --list", you will get the following:

$ git config --list
user.name=Scott Chacon
user.email=schacon@gmail.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

Get help from Git

If you ever need help while using Git, there are three ways to get the manual page help for any of the Git commands:
$ git help <verb>
$ git <verb> --help
$ man git-<verb>

For example, you can get the manpage help for the config command by running

$ git help config

These commands are nice because you can access them anywhere, even offline. If the manual pages and this book aren’t enough and you need in-person help, you can try the #git or #github channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.

Basic Operation on Git

To initiate a Git repository , you generally have two ways. One is using an existing project or directory and imports it into Git. The other is to clone an existing Git repo from another server.

Initializing a Repository in an Existing Directory

If you’re starting to track an existing project in Git, you need to go to the project’s directory and type

$ git init

This creates a new subdirectory named .git that contains all of your necessary repository files, which is a Git repository skeleton. At this point, nothing in your project is tracked yet.

If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a commit:

$ git add *.c
$ git add README
$ git commit -m 'initial project version'

At this point, you have a Git repository with tracked files and an initial commit.

Cloning an Existing Repo

If you want to copy from an existing Git repository , for example, a project you want to contribute to . The command you need is "git clone". Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run git clone.

To clone a repository , you should use git clone [url]. For example, if you want to clone the Ruby Git library called Ruby, you can do so like this:

$ git clone git://github.com/schacon/ruby.git

That creates a directory named grit, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new grit directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option:

$ git clone git://github.com/schacon/ruby.git ruby

That command does the same thing as the previous one, but the target directory is called myruby.

Git has a number of different transfer protocols you can use. The previous example uses the git:// protocol, but you may also see http(s):// or user@server:/path.git, which uses the SSH transfer protocol. It will be discussed in the next chapter.

Record Changes

Now we have a repo of the project , we can start to make changes and commit the changes into repo each time you think appropriate to mark a milestone.

Each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else. Any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything.

As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This cycle is illustrated in the figure below.

You can use the command "git status" to check the status of each file.Assuming you add a simple README file to your project and the file didn't exist before. When you run "git status" ,you can see this untracked file like this in below:

$ vim README
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   README
nothing added to commit but untracked files present (use "git add" to track)

Your new file is in the "untracked file" output. It means that Git doesn't find it in any previous snapshots and if you want Git to include it, you have to explicitly tell him so.

To track a new file like the README file you just added, you can use the command "git add" like this

$ git add README

Then you can run your status command again and you will get the following:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#

It’s under the “Changes to be committed” heading.If you commit now, this version of the file will be in the snapshot if you run git add. The git add command takes both file name or directory name.If it's a directory, the command will adds all the files in that directory recursively.

Branching

Introduction for Branching

Branching is a concept inn area of version control software, which allows users to duplicate source code and doing development parallel among different branches at the same time without messing up. Branching makes Git more special because of its extremely lightweight compared to other version control software. Branching in Git is fast and flexible. To development fast and powerful, it is important to master this feature.

Git stores data in a series of snapshots. Every commit in Git stores a pointer to any commit that came earlier. Similarly, a branch in Git is also a pointer to one commit. "Master" is the default name for branching. It is used when you first make commits, and it is always points to the last commit when more commits happen later.

Figure 4-1. Master branching pointing to commit history

The command git branch is used to create a new branch, which creates a new pointer into the current commit.

$ git branch test

HEAD is a special pointer which helps git to remember the current branch. git branch only creates a new branch without switching branching. Thus, you are still on the master branch. To switch branch, git checkout is used. The following command is for switching to the new test branch. It moves the HEAD pointer into the test branch.

$ git checkout test

At this time, when more commits happen, branch test that HEAD points to moves forward with new commits. However, branch master still points to the commit when we use git checkout to switch the branch as shown in Figure 4-2.

Figure 4-2. Pointer HEAD moves to another branch on command checkout

HEAD points to the current branch and the current branch points into the working directory. If we continue to make some changes and commits, the changes made at this point will diverge from the old version of the project as shown in Figure 4-3.

Figure 4-3. Branch diverged

Branch in Git is cheap to create and destroy because it only contains 40 character SHA-1 checksum of the commit that it points to. The speed to create a branch is as fast as writing 41 bytes to file, which is a great advantage compared to other version control software.

Merging

Merging is a basic operation in Git, which reconciles multiple changes. It is an important functionality in version control software which helps multiple developers works on the same project. Command is used to merge is:

$ git merge branch

There are two conditions might happen in Git when merging branches.

The first condition is when you are trying to merge a commit with another commit which can be find directly by following the first commit's upstream. In this case, no divergent work needs to be considered and the only work for Git to do is to move the pointer forward, which is called "fast forward".

In the second condition the two commits to be merged are not in the same commits stream that there are some divergent work needs to be taken care of. In this case, Git does a three-way merge. The two snapshots pointed to by the branches and the common ancestor of the two commits are used. In the process of three-way merging, Git creates a new snapshot to record and automatically creates a new commit for the new snapshot.

Developers do not need to worry about finding the best common ancestor that Git will does this work and saves time for developers.

There are some conflicts may happen in merging when the same part of the same file are changed differently in two branches. Developers have to resolve this problem before merging, otherwise you will get a merge conflict message looks like:

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

git status is used to check which files are not merged.

[master*]$ git status
index.html: needs merge
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   unmerged:   index.html
#

You can open the files that have conflicts manually and fix the problem.

You can also use merge tools which can be listed by command:

$ git mergetool

All the merge tools available are listed after "merge tool candidates".

Once you finish using merge tool and exit. Git will ask you whether you solve the conflicts successfully. If you answer yes, Git will stages file and records that as resolved. To finish merging, type command:

$ git commit

Manage your Branch

Many branch-management tools are available in using branches.

The command "git branch" has been introduced before, but it can do more than just creating and deleting branches. If there are no arguments come after "git branch", all current branches will be listed.

$ git branch
  iss53
* master
  testing

The "*" which prefix master indicates master is the branch which just check out.

If you want to have the last commit list after each branch, using "git branch -v":

$ git branch -v
  iss53   93b412c fix javascript issue
* master  7a98805 Merge branch 'iss53'
  testing 782fd34 add scott to the author list in the readmes

If you want to filter the branches list as only merged or unmerged, "--merged" and "--no-merged" can be used respectively as the argument.

To delete a branch that has not been merged will fail. The argument used to delete a branch is "-d".

Branching Workflow and Remote Branching

Long-running branches and topic branches are two kinds of workflows that developers can adopt in their development cycle.

In the workflow which has long-running branches, typically there are there branches: master, develop, and topic. Only codes are entirely stable are in the master branch, usually the codes are going to release are have been. And codes in develop are used for testing stability, which is not always stable. Develop is a parallel branch to master. When the codes in develop are make sure stable, the codes can be merged into master. Topic are temporary branch which still contains bugs and has not passe the test. Figure 4-4 shows the three branches.

Figure 4-4. Branches master, develop, and topic