About Revision Control Systems

Revision Control == Version Control

RCS == VCS

• Track code changes over a period of time
• Useful when multiple contributors work on the same piece of code

VCS is not for software projects only

VCSs are best-suited for tracking text files, but can be used for binary files like images, audios, videos etc

They are used for documentation projects, writing stories, books, articles etc

Examples: Subversion (SVN), Mercurial

Types of VCS

What is Git?

Git is a distributed version-control system which is famed to be extremely fast and flexible

A brief history

• Developed by Linus Torvalds as the version control system for the Linux kernel project
• The Linux kernel project is one of the largest, oldest and most well-kept Git repository

Why Git?

• Speed - Think of VCS with Saturn V rockets attached
• Reliability - Each revision is uniquely maintained
• Lightweight - Git core is extremely lightweight
• Plugins - For Emacs, Eclipse and other text editors
• Git is COOL

How popular is Git?

Terminologies

Let us look at some common terminologies associated with Git and VCS in general

Repository ("repo")

• A repository is the project folder
• Collection of all information related to a project, including project history, files, different branches
• Git repositories are stored in .git subfolders

Working tree

• State of the repository where all files are available for editing
• Files tracked by a repository can be changed only through a working tree

Bare repository

• A repo only with the .git directory, without a working tree
• Project files are stored in uneditable, compressed binary form
• Those files can be checked out to a working tree when they require editing
• Repositories on central servers are stored in bare form

Commits

• Changes saved in a repository are called commits in git
• Permanent snapshots of particular states of the repository

Pushing

Sending changes to a remote repository

Pulling

Fetching changes from a remote repository

Branch

• Particular flow of history within a repo
• Each branch can have a separate set of history
• Default branch in git is "master"

Merge

• Branches which have different changes can be merged together
• Merge conflicts arise if changes have been made to same file in different branches
• Branches can diverge if they have too different changes

Cloning

• Copying an existing repository
• Git can clone over various types of remote repos

Remotes

• A remote repo is a copy of the same repo in another location
• They are basically URLs pointing to remote copies of the repo
• Each remote in git is identified by a name
• Default remote after cloning is named "origin"

Fork

• A clone which is taken as a starting point for creating something different from the original repo
• A new copy of the entire repository
• Changes can be merged upstream from time-to-time

Introducing Git

$ git

The git command-line

Try Git tutorial

Getting help

$ git help

$ git help <sub-command>

Git version

$ git --version

Create your first repository

$ mkdir hello

$ cd hello

$ git init

Add a file for initial commit

<create a new file called README>

$ git add README

Check status

$ git status

README is now in staging area

# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   README
#
                        

Create the initial commit

$ git commit -m "Initial commit"

[master (root-commit) 9ff077b] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 README
                        

Check status

$ git status

First change has been committed

# On branch master
nothing to commit, working directory clean
                        

Do some changes

<make some changes to README>

Check differences

$ git diff

diff --git a/README b/README
index 96f0412..eeff8df 100644
--- a/README
+++ b/README
@@ -1 +1,3 @@
 This is my first repository
+
+This is the change for the second commit
                        

Add the file and commit

$ git add README

$ git commit -m "Modified README"

Check revision history

$ git log

commit 20ac39fb4e12237af37ae480f990eae2f4592a6b
Author: Kaustav Das Modak <kaustav.dasmodak@yahoo.co.in>
Date:   Fri Aug 30 13:57:43 2013 +0530

    Modified README

commit 9ff077b996e6cf917788d8d6393ef07fd9c2b753
Author: Kaustav Das Modak <kaustav.dasmodak@yahoo.co.in>
Date:   Fri Aug 30 09:43:12 2013 +0530

    Initial commit
                        

Another way to visualize Git Log

$ git log --pretty=oneline

20ac39fb4e12237af37ae480f990eae2f4592a6b Modified README
9ff077b996e6cf917788d8d6393ef07fd9c2b753 Initial commit
                        

Git Workflow

Diving into Git

• Branches
• Clones
• Merges

Branching in Git

$ git branch

* master

Create and switch to a new branch

$ git branch newbranch

$ git checkout newbranch

Switched to branch 'newbranch'

Shortcut
$ git checkout -b newbranch

Create a new file, add it and commit

<create a new file>

$ git add .

$ git commit

Commit message convention

• First line contains a brief description of what the commit is about (<= 50characters)
• Give double line breaks, followed by a detailed description
• Lists appear with hyphens in the beginning
• Use double line breaks to separate paragraphs
• Write commit messages in imperative

Example commit message

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug."  This convention matches up with commit messages generated
by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded by a
  single space, with blank lines in between, but conventions vary here

- Use a hanging indent
                        

Modify previous commit message

$ git commit --amend

.gitignore

Have git ignore certain files

• One pattern per line
• One .gitignore file per directory
• Rules cascade through sub-directories

Merge changes with another branch

$ git checkout master

$ git merge newbranch

Updating 20ac39f..9f16d40
Fast-forward
 ME | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 ME
                        

Clone a repo

$ git clone <remote url>

Browse through the repo

Use $ git log, create branches, do edits and commits, e.g.:

$ git checkout -b patch-1

Push changes to origin

$ git push origin patch-1

Delete a local branch

$ git branch -d patch-1

Delete a remote branch

$ git push origin :patch-1

Working with Forks

Begin a fork by cloning a repo

Work on a new branch

Merge changes periodically from upstream

Setting an upstream

$ git remote add upstream <upstream url>

Pull changes from upstream

$ git pull upstream

A better way to pull

$ git fetch upstream

$ git merge upstream/<branch>

Now you can push to origin and merge changes occassionally from upstream