Version Control with GIT

Alex Pacheco
LTS Research Computing

Overview

What is Version Control?

  • A version control is a system that records changes to a file (or set of files) over time.
  • It makes easier to
    • work with another developers,
    • revert files back to a previous state,
    • compare changes over time,
    • see who modified what and when,
    • and more.
  • Examples of collaborative work
    • web development,
    • software development,
    • preparing scientific publications, reports and
    • writing your dissertation.

Why you should use Version Control?

Types of Version Control

Local Version Control

  • earliest form of version control
  • simple database that kept all changes to files under revision control
  • Examples:
    • Source Code Control System (SCCS)
    • Revision Control System (RCS)

Types of Version Control

Centralized Version Control Systems

  • uses a central server to store all files and enables team collaboration
  • single point of failure, i.e., failure of the central server
  • central server goes down for an hour, then during that hour, no one can collaborate at all
  • if the disk of the central server gets corrupted and proper backup has not been taken, then you will lose the entire history of the project
  • Examples:
    • Concurrent Versions System (CVS)
    • Subversion

Image not found

Types of Version Control

Distributed Version Control Systems

  • clients fully mirror the repository
  • if the server goes down, then the repository from any client can be copied back to the server to restore it
  • does not rely on the central server and that is why you can perform many operations when you are offline
  • require network connection only to publish your changes and take the latest changes.
  • Examples:
    • Git
    • Mercurial

What is Git?

  • Git is currently the most popular implementation of a distributed version control system
  • founded in 2005 by Linus Trovalds for the Linux Kernel development
  • used by many popular open source projects, e.g., the Android or the Eclipse developer teams, as well as many commercial organizations
  • Advantages:
    • Free and open source
    • Fast and small
    • Implicit backup
    • Security
    • No need for powerful hardware
    • Easier branching

Git Terminologies

  • Repositories: contains the history of a collection of files starting from a certain directory
    • bare repositories: used on a server for sharing changes coming from different developers
      • do not allow the user to modify locally files and to create new versions for the repository based on these modifications
    • non-bare repositories: target the user
      • allow you to create new changes through modification of files and to create new versions in the repository
    • a local non-bare Git repository is typically called local repository
  • Cloning: process of copying an existing Git repository

Git States & Workflow

  • Git directory is where Git stores the metadata and object database for your project
  • working directory is a single checkout of one version of the project
  • staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit
  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.

Installing Git on Linux

  • install via package manager

    • Debian Family
    sudo apt-get install git-all
    
    • RedHat Family
    sudo yum install git-all
    
    • SuSE Family
    sudo zypper install git
    

Installing Git

Configuring Git

  • Setup username and email address
git config --global user.name "Enter your name"
git config --global user.email "Enter your email address"
  • Setup your editor, default is vi
git config --global core.editor emacs
  • Notepad++ is recommeded for Windows Users
git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession"
  • MobaXterm has vi while emacs can be installed using apt-cyg install emacs

Check Settings

git config --list
## user.name=Alex Pacheco
## user.email=abpacheco@gmail.com
## push.default=simple
## alias.lg=log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
## alias.pub=push webapps +gh-pages:refs/heads/master
## core.repositoryformatversion=0
## core.filemode=true
## core.bare=false
## core.logallrefupdates=true
## core.ignorecase=true
## core.precomposeunicode=true

Create a Git Repository

  • Initializing a Repository in an Existing Directory
git init git-train
## Initialized empty Git repository in /Users/apacheco/Tutorials/DCVS/bitbucket/git-train/.git/
  • Create a readme file, stage and commit to repository
touch README
git add README
git commit -m "My First commit"
## [master (root-commit) a8e897e] My First commit
##  1 file changed, 1 insertion(+)
##  create mode 100644 README

Create a Bare repository for collaborating

  • Create a bare repository (give it an extension .git) at a location convenient for sharing
git init --bare git_train.git
  • Clone the repository in your local directory, now called local repo
git clone file://{path to bare repo}/git_train.git
  • Now you can edit files in the local repo and treat the bare repo as a remote repository
  • Any changes you make and commit are in your local repo that your collaborators will have access only after you push your commits to the remote
  • Your bare repo can be accessed via different protocols
    • file (local)
    • ssh (remote): git clone ssh://user@server/{path to bare repo}/git_train.git
    • http/s (remote): git clone https://serverurl/git-train.git

Lifecycle of a file

  • each file in your working directory can be in one of two states: tracked or untracked
  • tracked: files that were in the last snapshot; they can be unmodified, modified, or staged
  • untracked: everything else – any files in your working directory that were not in your last snapshot and are not in your staging area

Check Status of git repository

git status
## On branch master
## nothing to commit, working directory clean
  • implies that you have a clean working directory
    • i.e. no tracked and modified files
  • Git doesn't see any untracked files
  • you are working on the master branch

Working on a Git reposiotory

  • lets make some changes
    • modify README file
    • create a index.html file
    • stage both files and
    • commit to repository

Create & Modify Files

cat << EOF > README
## Description
My first git repository

## Project
Building a webpage
EOF
cat << EOF > index.html
<!doctype html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>My First Webpage</title>
  </head>

  <body>
    <article>
      <h2>Under Contruction</h2>
      <p>No soup for you. Come back one year!</p>
    </article>
  </body>
</html>
EOF

Check Status

git status
## 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)
## 
##  modified:   README
## 
## Untracked files:
##   (use "git add <file>..." to include in what will be committed)
## 
##  index.html
## 
## no changes added to commit (use "git add" and/or "git commit -a")

Staging modified files

git add README
## On branch master
## Changes to be committed:
##   (use "git reset HEAD <file>..." to unstage)
## 
##  modified:   README
## 
## Untracked files:
##   (use "git add <file>..." to include in what will be committed)
## 
##  index.html

Tracking new files

git add index.html
## On branch master
## Changes to be committed:
##   (use "git reset HEAD <file>..." to unstage)
## 
##  modified:   README
##  new file:   index.html
  • Status check (using short form -s)
git status -s
## M  README
## A  index.html

Commit your changes

git commit -m "Created index.html, modified README with useful information"
## [master 5dccf54] Created index.html, modified README with useful information
##  2 files changed, 18 insertions(+)
##  create mode 100644 index.html
  • You can commit using the command git commit
    • you will need to enter a commit message in your favorite editor
    • you cannot commit without a commit message
  • Verify what we've done
git status
## On branch master
## nothing to commit, working directory clean

Skipping staging area

  • For tracked files, it is possible to skip the staging area and go directly to the commit
  • Add -a flag to git commit command
git commit -a -m
# OR
git commit -am

Review Commit history

git log
## commit 5dccf54e60fe54278e1ce02a34f4e15e0e21eda5
## Author: Alex Pacheco <abpacheco@gmail.com>
## Date:   Mon Oct 31 20:21:01 2016 -0400
## 
##     Created index.html, modified README with useful information
## 
## commit a8e897e45466f1f713d528aa6d246c5af633b6f0
## Author: Alex Pacheco <abpacheco@gmail.com>
## Date:   Mon Oct 31 20:21:01 2016 -0400
## 
##     My First commit

Git Log Command options

git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s"
## 5dccf54e60fe54278e1ce02a34f4e15e0e21eda5 Created index.html, modified README with useful information
## a8e897e45466f1f713d528aa6d246c5af633b6f0 My First commit
## 
## 5dccf54 - Alex Pacheco, 1 second ago : Created index.html, modified README with useful information
## a8e897e - Alex Pacheco, 1 second ago : My First commit

Removing Files

  • To delete a file, you need to remove it from tracked files and then commit
rm Project.md
git status
git rm Project.md
## On branch master
## Changes not staged for commit:
##   (use "git add/rm <file>..." to update what will be committed)
##   (use "git checkout -- <file>..." to discard changes in working directory)
## 
##  deleted:    Project.md
## 
## no changes added to commit (use "git add" and/or "git commit -a")
## rm 'Project.md'

Stop Tracking files

  • Sometimes, you might want to stop tracking a file but not delete it completely
  • Add a --cached option to git rm
git rm --cached About.md
## rm 'About.md'
## On branch master
## Changes to be committed:
##   (use "git reset HEAD <file>..." to unstage)
## 
##  deleted:    About.md
##  deleted:    Project.md
## 
## Untracked files:
##   (use "git add <file>..." to include in what will be committed)
## 
##  About.md

How to ignore untracked files

  • contains a list of files that git will ignore and not track them
    • emacs users ... add *~ to .gitignore to not track buffer files
    • vi users ... add *.swp to .gitignore to not track swap files
echo About.md > .gitignore
## On branch master
## Changes to be committed:
##   (use "git reset HEAD <file>..." to unstage)
## 
##  deleted:    About.md
##  deleted:    Project.md
## 
## Untracked files:
##   (use "git add <file>..." to include in what will be committed)
## 
##  .gitignore

Rename Files

  • To rename files, use the git mv command
git mv README README.md
## On branch master
## Changes to be committed:
##   (use "git reset HEAD <file>..." to unstage)
## 
##  deleted:    About.md
##  deleted:    Project.md
##  renamed:    README -> README.md
## 
## Untracked files:
##   (use "git add <file>..." to include in what will be committed)
## 
##  .gitignore

Undoing Things

  • If you
    • committed too early,
    • forgot to add files, or
    • error in Commit message
  • The --amend option to git commit takes your staging area and uses it for commit
git commit -m 'Deleted Project.md, Renamed README and untracked About.md'
git add .gitignore
git commit --amend -m 'Deleted Project.md, renamed README, untracked About.md and added .gitignore'

Undoing Things

## [master 485d6ad] Deleted Project.md, Renamed README and untracked About.md
##  3 files changed, 0 insertions(+), 0 deletions(-)
##  delete mode 100644 About.md
##  delete mode 100644 Project.md
##  rename README => README.md (100%)
## 
## 
## [master b33a696] Deleted Project.md, renamed README, untracked About.md and added .gitignore
##  4 files changed, 1 insertion(+)
##  create mode 100644 .gitignore
##  delete mode 100644 About.md
##  delete mode 100644 Project.md
##  rename README => README.md (100%)

Working with Remote Git Repositories

  • Remote repositories are versions of your project that are hosted on the Internet or network somewhere
  • Github and Bitbucket are the most common web-based Git repository hosted services
  • Library & Technology Services provide a Git hosted services that is accessible within Lehigh only

  • Creating a repository on a hosted service i.e. remote repository

  • Pushing your local git repo to the remote repository

  • How to check remote repositories

    git remote -v
    
  • how to add remote repository

    git remote add <shortname> <url>
    

Working with remote repository

  • What if you want to collaborate with someone and want to take a copy of their repository

    • The remote you clone from will be called origin
    • There has to be at least one remote repo named origin git clone https://gogs.cc.lehigh.edu/alp514/git-train.git
  • Push changes in local repo to remote

    git push <name> <branch>
    
  • Update changes from remote to your local repo

    • First fetch the latest snapshot from the remote
    • Merge the latest snapshot to your local repo git fetch git merge HEAD
  • Alternatively, run git pull which will do the above two commands

Working with remote repository

  • Adding another remote

    git remote add github https://github.com/alexpacheco/git-train.git
    
  • Listing your remotes

    git remote -v
    
  • Renaming a remote

    git remote rename github backup
    
  • deleting a remote

    git remote rm backup
    

Tagging

  • Git has the ability to tag specific points in history as being important.
  • Create annotated tags
git tag -a v1.4 -m "my version 1.4"
  • Tag a previous commit with commit checksum 9fceb02
git tag -a v1.2 9fceb02
  • List all your tags
git tag

Tagging

  • To push specific tag to remote server
git push origin [tagname]
  • To push all tags to remote server
git push origin --tags
  • Checkout a tag to a new branch
git checkout -b [branchname] [tagname]

Branches

  • Branching means you diverge from the main line of development and continue to do work without messing with that main line

  • Create a new branch

git branch testing

Branches

  • Switch to new branch
git checkout testing

Branches

  • Make a change (in testing branch) and commit

Branches

  • Switch to master branch
git checkout master

Branches

  • Make some changes and commit

  • Now you have two options:
    • Continue development on two divergent branches
    • Merge the testing branch with the master git merge testing and
      • continue to maintain two branches, or
      • delete the testing branch git branch -d testing

Questions?