GitDistributed Version Control System

Version Control Systems

• Keep track of changes to a set of documents• Source code files, configuration files, documentation, etc.

• Associate each version of a software to the files from which it was built

• Compare different versions of a software

• Parallel development• Facilitate collaboration among developers

• Allow developing along multiple directions• e.g. new feature development vs bug fixing

• Efficient storage in a repository

• Backup copies

History of Version Control Systems

• Single-user VCS• Single repository accessible from one user at a time

• Examples: SCCS, RCS

• Centralized VCS (client-server architecture)• Central server with repository accessed by all developers

• Examples: CVS, Subversion, ClearCase, Visual SourceSafe

• Distributed VCS• No central server, each user maintains a local repository

• Examples: Bazaar, Git, Mercurial, BitKeeper

VCS concepts

• Repository: data base with history of changes to a set of files

• Revision or version: snapshot of files at a specific point in time

• Working copy: files at a specific revision, with changes from a user

• Check out: mark a file as being modified by a user

• Check in or commit: update repository with changes from a user

• Change set: list of changes to each file in a single check in

• Tag: label applied to a specific revision

Development tree

• Trunk: main development line

• Branches: parallel development lines

• Merge: coalesce changes from different branches• Merge conflict: different changes to the same piece of code

Git

• Distributed VCS

• Open-source, popular for open-source projects

• Available for all major operating systems: Windows, Linux, Mac

• Command line interface, with 2 built-in graphical tools• Git Gui (to apply changes to a repository)

• Gitk (to browse contents of a repository)

• On Windows, command line interface is accessed with Git Bash

• Various graphical front-ends from third parties• SourceTree, GitHub for Windows, GitHub for Mac, Git-cola, SmartGit, etc.

Atlassian SourceTree

• Free Git graphical frontend for Windows and Mac

• http://sourcetreeapp.com/

• Uses command line Git executable• System Git or embedded Git

• Support for local and hosted repositories• Built-in support for BitBucket, GitHub and Stash hosting services

• Hosted repositories managed with local clones• Local repositories automatically synchronized with remote repositories

Git Configuration

• User identification: name and e-mail address• Necessary to associate each commit to its author

• Git can be configured from command line• git config

• SourceTree allows accessing Git configuration• Tools -> Options

• In General tab, insert full name and email address in default user information section

Git Repository Creation

• Example: Git repository for a Java project

• Create new Java project HelloWorld with a class com.example.HelloWorld

• Initialize Git repository for project:• File -> Clone / New…

• Create New Repository

• Browse for the project directory

• Create

Repository and Working Copy (1/2)

• In filesystem, visible files are those in working copy, repository is “hidden”

• Files in working copy but not in repository are untracked files

• Untracked files and changes to files in a working copy must be stagedbefore they can be committed• From SourceTree: select files from Working Copy Changes and click on

Actions -> Add

• Items are moved from Working Copy Changes to Staged Changes

• To undo, click on Actions -> Unstage from index

• To discard changes in working copy: Repository -> Discard…

Repository and Working Copy (2/2)

• Build output files should not go to repository

• Tell Git to ignore them: .gitignore file in top-level directory

• From SourceTree: Repository -> Repository Settings• Advanced tab -> Repository-specific ignore list

• Java project example:• bin/ directory should be ignored

• HelloWorld.class file not in Working Copy Changes

• Add .gitignore to repository

Commit

• Puts into repository staged changes from working copy

• Creates a new revision in repository

• Commit message: description of changes in the commit

• To perform a commit from SourceTree• Repository -> Commit All…

• Write message in Commit Message text field and click on Commit

• The new commit appears in the Log / History tab

• Commit id: 160-bit SHA-1 hash• First 7 hexadecimal characters typically used as short form

Diff

• Visualizes changes to files in a standard format

• From SourceTree: select file from Working Copy Changes or Staged Changes or commit changes

• Diff output example:

Git Branches

• master is the name of the main branch (trunk)

• Current branch: branch to which commits are applied

• Tip or head of a branch: last commit in that branch

• HEAD: head of current branch

• To create new branch: Repository -> Branch…• By default, new branches start from HEAD

• To change current branch: Repository -> Checkout…• Select head of branch to set as current branch

Commit History (1/2)

• To see history of commits on a branch, select the branch

• Example:

• Branch icon on branch head

• Select a commit to view commit details• Author, date, commit id, changes in diff format, etc.

Commit History (2/2)

• To see history of changes for a specific file:• Select file

• Actions -> Log Selected…

• To see last commit and author where a part of a file has been modified:• Select file

• Actions -> Blame Selected…

• To set working copy as in a specific commit:• Repository -> Checkout…

• Select commit• Detached HEAD

Reset and Revert

• Delete commits done after a specified commit

• From SourceTree:• Right-click on commit

• Reset current branch to this commit

• Reset modes:• Soft – keep all local changes

• Mixed – keep working copy but reset index

• Hard – discard all working copy changes

• Revert• Add a commit undoing changes from a past commit

Merge

• Applies commits from a branch to another branch

• To perform a merge:• Make destination branch the current branch

• Execute merge from source branch

• Example: merge branch “develop” into branch “master”• Repository -> Checkout… (select “master”)

• Repository -> Merge… (select head of branch “develop”)

• Result:

Fast-Forward vs True Merge

• Fast-forward: when head of destination branch is ancestor of commit to merge• When merging, no new commits are created

• True merge: when the above does not hold• A merge commit is created

• Example of true merge:

Merge Conflicts (1/3)

• Parallel development on multiple branches

• Changes to same file from different branches

• Merge one branch into another: (potential) merge conflict

• Example:• Third commit in develop branch:- System.out.println("Hello, world!");+ System.out.println(“Bye, world!");

• Third (conflicting) commit in master branch:- System.out.println("Hello, world!");+ System.out.println("See you, world!");

Merge Conflicts (2/3)

• Trying to merge develop into master:

• Conflicted file contents:<<<<<<< HEAD

System.out.println("See you, world!");=======

System.out.println(“Bye, world!");>>>>>>> develop

Merge Conflicts (3/3)

• To fix merge conflicts:• Edit manually conflicted files

Or

• Use SourceTree conflict resolution tools• Select conflicted file

• Actions -> Resolve Conflicts -> Resolve Using ‘Mine’• To use file contents from destination branch (current branch)

• Actions -> Resolve Conflicts -> Resolve Using ‘Theirs’• To use file contents from source branch

• Actions -> Resolve Conflicts -> Mark Resolved

• Commit

Tags

• Name associated to commit

• To create new tag from SourceTree:• Repository -> Tag…

• Tag name

• Commit

• Optional tag message

• Annotated tag: contains creation date, creating user and message

• Lightweight tag: simple name

Remote Repositories

• Git as distributed VCS uses local repository

• Necessary synchronization between repositories

• Git remote: reference to remote repository

• Remote-tracking branches

• Typical use: clone• From SourceTree:

• File -> Clone / New…

• Clone Repository

• “origin” remote

• Local branch created from current branch in remote

Repository synchronization

• Fetch: from remote to local• Update remote-tracking branches

• Pull: from remote to local• Fetch from remote and merge into local current branch

• In SourceTree:• Repository -> Pull…

• Select remote and remote branch to pull

• Push: from local to remote• In SourceTree:

• Repository -> Push…

• Check local branches to push and select corresponding remote branches

Rebase

• Branch feature/x created from develop

• develop is updated

• Rebase feature/x against develop:

• From SourceTree:• Chek option “Rebase instead of merge” when merging or pulling

• Merge conflicts:• Resolve conflicts

• Actions -> Continue Rebase

Patches

• Standard format to describe changes

• Allows synchronization without accessing remote repositories• Typical use: e-mail communication

• To create patches from SourceTree:• Actions -> Create Patch…

• Select changes from either working copy, staging area or past commits

• Simple diff vs full commit info

• To apply patches from SourceTree:• Actions -> Apply Patch…

• Apply to either working copy or staging area, or import commit

Stash

• Return to clean working copy without losing changes

• From SourceTree: Repository -> Stash Changes…• Keep staged changes option

• Stashed changes can be restored on a different HEAD• Conflicts might occur

• Use case examples:• Pulling into a dirty tree

• Interrupted workflow

• Testing partial commits

Submodules

• External software components reused within a project

• Reference to remote repositories for components

• Superproject• Submodule A

• Submodule B

• …

• From SourceTree:• Repository -> Add Submodule…

• Submodule update: Git pull

Git Flow

• Standardized branching model for software projects

• Branch naming conventions

• Two main branches:• Production branch (master)

• Keeps track of releases

• Tagged with release names

• Development branch (develop)• Receives new features as they are completed

• Receives bug fixes and other improvements

• Supporting branches

Git Flow: Feature Branch

• Also called topic branch

• Created from develop

• Named after feature being developed

• Development of a new feature

• Merged into develop

Git Flow: Release Branch

• Created from develop

• Preparation for new software release• Bug fixes and other improvements

• Feature freeze

• Merged into master and develop

Git Flow: Hotfix Branch

• Also called maintenance branch

• To fix release problems before next major release

• Created from master

• Bug fix

• Merged into master and develop

Git Flow in SourceTree

• Repository -> Git Flow menu• Initialize Repository

• Create main branches

• Choose name prefixes for supporting branches and release tags

• Start New Feature• Create and check out feature branch

• Finish Feature• Merge and delete feature branch

• Start New Release/Hotfix• Create and checkout release/hotfix branch

• Finish Release/Hotfix• Merge and delete release/hotfix branch, tag master