git session-2012-2013

Git Source Control Management

José Manuel Vega MonroyMálaga, 2012-2013

Index

1. Git Basics

2. Working with Git: Novice

3. Working with Git: Advanced

4. Working with Git: Utilities

Fundamental Concepts of Source Control Management

● Source control management (SCM): Records of information about an evolving software project (examples: CVS, SVN, Mercurial, TLA, etc.)

● Project: Set of files and directories, typically comprising the source files of a software system under development, but could be any other “content” (pictures, documents, etc.)

● Version: One instance of a project (sometimes called a commit in SCM systems)

More Fundamental Concepts of Source Control Management

● Branch: A sequence of versions, each one evolved from the previous one

● To branch: Split development into two parallel branches● To merge: Combine two branches into single branch● References in history: Each commit or merge● Tag: A friendly name for a version (for example, “version

1.0”)

Traditional Architecture of Source Control Management

● Server: Database (file repository)● Clients: Working version or “workspace” (local copy which

developer works)

More Fundamental Concepts of Source Control Management

● Repository: In this case, a specialized database to store an evolving project with its branches (commit history)

● Remote repository: ANY repository in the system● Remote “local” repository: In Git, locally, you have a

repository similar to ANY REMOTE repository

Git is a SCM (Source Control Management System)

● Management of changes in any file: documents, programs, and other information stored as computer files

○ Developed by Linus Torvalds (“Mr. Linux”)○ Its first usage have been to facilitate Linux Kernel

development○ It's OPEN SOURCE and FREE○ Consider CVS/SVN as “the Evil” (it's not an evolution of

them)

Git: A Fast Version Control System

● Git ○ Is distributed (no central repository)○ Has no master copy○ Has very fast merging and branching (good

performance)○ Is controversial (new paradigm in SCM systems)○ Difficult to master (it's better to learn it through everyday

usage)○ Scales up○ Convenient tools still being built (it's recommend to work

from command line) ○ Safeguards against corruption (tracking the whole

repository, not only files)

CVS/SVN Distributed Architecture: Client-Server

System of centralized repository: R1

Oval is server

R1

C2 C3

C1

C4

Boxes are individual clients

Git Distributed Architecture: P2P (“Island” Model)

Repository as “island”: R1

Oval is server

R1

Git Distributed Architecture: P2P (“Island” Model)

System of distributed repositories: R1, R2, R3,...

Ovals are servers

Boxes are individual repositories

R1 R2R3

R4 R5

Protocols: SSH, Rsync,

HTTP, Git protocol, etc.

Integration with: SVN (git-svn),

CVS, etc.ME

CURRO

Git Individual Repository

● Index: Temporal cache to store information about current working directory and changes made to its objects (files, directories, etc.)

○ “Snapshot” for the current state of every tracked file● Object Storage: Storage for the project versions (directory

called .git, in the top level of the repository) ○ Commits (hash of parent, name of author, time of commit,

and hash of the current tree)○ Tags○ Trees (directories)○ Blobs (files)

Git Individual Repository:Architecture

addcommit

Any Repository

Object storage

pull, fetch

More Repositories (remotes)

push push

Working tree (sand box)

Index(cache)

Object storage

pull, fetch

checkout

commit -a

Directory .git

Git Individual Repository:More Architecture

addcommit

BARE Repository

Object storage

pull, fetch

More Repositories (remotes)

push push

Working tree (sand box)

Index(cache)

Object storage

pull, fetch

checkout

commit -a

Directory .git

Data Structure of Repository: Repository Nodes

commit

tree

blob

version

files

tree of folders

NODE

● A repository contains many nodes● Each node is a tree like a representation

of files following the folder structure on disk

● Each “tree-root” version is based on zero or more previous versions

● Each folder is a new tree containing other folders and files (blobs)

● Generally, this committed structure is immutable

Data Structure of Repository: Family of Nodes (Logical View)

Data Structure of Repository: Family of Nodes (Physical View)

● By default, Git has got a specific tag called HEAD, one repository “pointer” that normally points at the LATEST COMMIT -last node in the repository- of the CURRENT BRANCH

● And it allows to move it: BACK TO THE PAST

● As it could be moved, FOR NOT LOSE THE HEAD, Git saves the original as a tag called ORIG_HEAD

Data Structure of Repository: HEAD

a------b------c <-- master

HEADHEAD^HEAD^^HEAD^^=HEAD^2=HEAD~2

Data Structure of Repository: More HEAD

HEAD: Pointer to the reference for the current branch

// in branch "master" git checkout master

// in branch "topic" git checkout topic

Data Structure of Repository: More HEAD

Reference for branch “test”:refs/heads/test

Reference for branch “master”:refs/heads/master

HEAD: Physically, it contains "refs" values (for example, “refs/heads/test”)

● In a node, every part is named with a hash (SHA1) of its contents (if something change, it detects using SHA1: data integrity!)

● Logically, identical files would have got the same hash, but Git represented them by a single blob

● Version is simply a text file with some meta data: hash name, parent, author and committer

● A version hash name can be used as a “pointer” to locate the tree and its corresponding content

● To be easier, Git allows to use a tag instead of SHA1 as version hash name

Data Structure of Repository: Hash Names

● Short SHA:○ Git is smart enough to know what commit you mean when

you type the first few characters○ Always when there is no ambiguity○ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b○ git show 1c002dd4b536e7479f○ git show 1c002d

Data Structure of Repository: More Hash Names

● SHA collisions:○ It could occur two different commits with the same SHA in

different position on the commit history○ In this case, you only could get the data of the first object○ The number of randomly hashed objects needed to ensure

a 50% probability of a single collision is about 2^80 (1 million billion billion): VERY VERY VERY DIFFICULT!!!

Data Structure of Repository: More Hash Names

Data Structure of Repository: Conventions

Data Structure of Repository: Aliases

● List repositories○ By convention, the name of Git bare repository is ended

with .git (any other repository not)○ But actually any repository is REFERENCED REMOTELY

BY ALIAS (“origin” by default)○ git remote // show all the stored alias for repositories○ git remote show origin // show more information about the remote

repository called with the alias “origin”* remote origin Fetch URL: file:///home/josevega/test1.git Push URL: file:///home/josevega/test1.git HEAD branch: master Remote branches: master tracked test tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)

Data Structure of Repository: More Aliases

● Add and remove repositories○ git remote add github [email protected]:schacon/hw.git // add

alias called "github" with reference "[email protected]:schacon/hw.git"○ git remote rm origin // remove alias called “origin” ○ git remote rename origin github // rename “origin” to “github”

Data Structure of Repository: Access

● Access by reference:○ Each alias is actually a URL reference to repository,

local or remote○ URL is the global address of documents and other

resources on the World Wide WebURL = Protocol Identifier + Host Name + Resource Location

○ git remote -v // show basic information (URL) for default remote repo○ git remote set-url origin git://github.com/jmvm/ticgit.git // add

or update the given URL for the alias “origin” (the same for pushing and fetching)

○ git remote set-url origin git://github.com/jmvm/ticgit.git --push // add or update the given URL for the alias “origin” (only for pushing)

○ Another way is to modify configuration global parameter called remote.alias_name (where “alias_name” must be the given alias name)

Data Structure of Repository: URL Examples

ssh://[user@]host.xz[:port]/path/to/repo.git/git://host.xz[:port]/path/to/repo.git/http[s]://host.xz[:port]/path/to/repo.git/ftp[s]://host.xz[:port]/path/to/repo.git/rsync://host.xz/path/to/repo.git/ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/git://host.xz[:port]/~[user]/path/to/repo.git/[user@]host.xz:/~[user]/path/to/repo.git//path/to/repo.git/file:///path/to/repo.git/

Local remote repositories

Key Git Files/Directories● Project configuration

○ .git/config has the local repository specific configuration○ Usually it contains the paths for remotes repositories

● Records for commits○ .git/logs contains commits logging history for branches

● Hash values○ .git/objects is a collection of objects indexed by SHA1

● Configuration file for ignoring files○ The file is called .gitignore, containing a list of files that you

want to ignore○ Put it into the directory that contains the files to ignore

More Key Git Files/Directories● Git tasks scripts

○ .git/hooks contains several scripts with Git tasks● Empty directories

○ By default, Git ignores empty directories○ To track one, put a blank file called .gitkeep inside

More Key Git Files/Directories● Git references

○ .git/refs contains any reference for Git○ .git/refs/heads contains references for branches in the local

repository○ HEAD is physically stored into .git/HEAD, and contains the

reference to the current branch (for example, “refs/heads/master”)

○ .git/refs/tags contains the commits tags (if any)○ .git/refs/remotes contains the remote references (if any)○ Git allows to modify manually these references: with any

text editor or git update-ref

Git Individual Repository:Workflow

Git Individual Repository:More Workflow

Index

1. Git Basics




Key Git Operations Resume 1) Init. Create an empty Git

repository2) Clone. Copy a repository into a

new directory. After cloning, edit, create and remove files for new version

3) Add. Add file contents from workspace to the index. (The files are edited locally)

4) Remove = rm. Remove files from work space and from the index

5) Commit. Store the changes (that are added) to the repository, using the index. Completes this version.

6) Branch. Create (or delete) a branch

7) Merge. Join two or more branches

8) Rebase. Combine/restructure a set of commits to simplify them

9) Checkout. Checkout files etc from a commit, and switch workspace to that new branch

10) Fetch. Download objects and refs from another repository

11) Pull. Fetch from and merge with another repository or a local branch

12) Push. Update remote refs (in another repo) along with associated objects

Everyday tasks with Git: Starting!

● Introduce yourself to Git○ git config --global user.name “Glass”○ git config --global user.email “[email protected]”○ There are many options to work more “comfortable”○ git config --help○ git config --list // list options for current configuration○ git config --global help.autocorrect 0 // auto correction when a

command is wrong by command line (only for Git 1.6 or superior)○ git config --global core.editor emacs // core text editor○ git config --global core.autocrlf true // convert final LF to CRLF

mailto:[email protected]

Everyday tasks with Git: More Starting!

● Coloring the screen○ git config --global color.status auto○ git config --global color.ui true // colors by default○ git config --global color.branch auto○ git config --global color.interactive true○ git config --global color.diff true○ git config --global color.status.added “green bold”○ git config --global color.status.changed “yellow bold”○ git config --global color.status.untracked red○ git config --global color.sh.branch yellow


● Automatic message for commits○ It's possible to define a template by default○ For example, a file called .gitmessage with the next

structure:Subject line: brief summary on what happenedWhat happened: explanation on what was done, with sufficient level of detail[ticket Id in JIRA: GRB-XXX]

○ git config --global commit.template ~/.gitmessage


● Git Commands Aliasing○ AUTOCOMPLETE is very useful○ As well Git allows to use ALIAS○ git config alias.com commit // make alias “com” for commit○ git config alias.co checkout // make alias “co” for checkout○ git config alias.br branch // make alias “br” for branch○ Once you create a command alias, Git allows you to

autocomplete it


● Help me!○ Git always offers you help○ git help○ git command_name --help // man page for the command

“command_name”


● My status○ What is the status respect my local repository?○ If you have made changes, the status will show your locally

modified items○ All turn around of working copy status, so REMEMBER:

if you don't know what is happen, have a look your status!

○ git status○ git status -s // tradicional short view as SVN (' ' = unmodified, A =

added, M = modified, D = deleted, R = renamed, C = copied, U = updated but unmerged)

○ git status --ignored // show the ignored files by .gitignore as well

Everyday tasks with Git: Init repository

● Create a repository○ git init test1 // create the basic artifacts in the .git directory

Initialized empty Git repository in /home/josevega/test1/.git/

○ By default, this repository is a local working copy: working repository

○ Sometimes it's useful for developers to have a central repository: bare repository

○ git init --bare test1.gitInitialized empty Git repository in /home/josevega/test1.git/

○ By convention, a bare repository should end in .git○ Anyway, every Git repository is stored in the .git directory

in which the Git repository has been created○ As advice, make a first commit to init the current project

in the repository

Everyday tasks with Git: Cloning

● Clone a repository○ It's possible to replicate a remote repository○ Cloning copies “magically” the whole remote repository

to the local repository in a specific branch○ That repository is a working repository (CLONE = INIT +

FETCH), and has got the alias ORIGIN by default○ Git supports several transport protocols (native protocol

is called git)○ git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.

git○ git clone git://git.debian.org/scm/git/git.git ○ git clone ssh://[email protected]/var/git/project.git○ git clone file://var/git/project.git

Everyday tasks with Git: Cloning Example

Everyday tasks with Git: Cloning Example

Pointer to the remote repository ("remote-tracking" branch)

Pointer to the local repository ("tracking" branch)

Everyday tasks with Git: Playing

● Playing with remote “repositories”○ Repositories are something dynamic○ So it's possible to “play” with the REFERENCES to remote

repositories○ git remote add new_repo git://github.com/jmvm/ticgit.git○ git remote rename new_repo rn // rename the reference from

“new_repo” to “rn”○ git remote rm new_repo // delete the reference to “new_repo”

Everyday tasks with Git: More Playing

Everyday tasks with Git: Branching

● List branches○ You are ALWAYS on a branch○ Repositories branches can be local ("TRACKING"

branch) or remote ("REMOTE-TRACKING" branch)○ master is the default branch name (by convention, don't

delete neither rename)○ git branch // list available of local branching○ git branch -r // list available of remote-tracking branches (remote)○ git branch -a // list available of local and remote-tracking branches (all)○ git branch -f my_new_branch // force updating to branch initial point

Everyday tasks with Git: More Branching

Branches: Physically, POINTERS to commits on a COMMIT HISTORY


● Create a branch○ Developers use branches frequently○ Typical situation when you want to create a new

functionality of your current project○ git branch my_new_branch // create a new branch from current point○ git checkout -b my_new_branch // create a branch, and checkout

with the last commit (signaled by HEAD)○ git checkout -b my_new_branch master^1 // based on “master”

(the commit before the last commit)○ In the same way, you could delete a branch○ git branch -d my_new_branch


● Local branches○ You work with local branches○ Normally each branch have got its corresponding branch

remotely○ For example, when you clone, automatically all local

branches are tracked respect on the remote repository branches: references -links- between branches are created

○ But sometimes it's necessary to track the local branch with any other remote branch

○ git branch --track develop origin/develop


● Move into a branch○ Free move between branches○ If you decide to work on a branch, you could checkout

this branch○ Checkout is an action in which the HEAD pointer is

moved to the latest commit of the branch○ git checkout my_new_branch○ Untracked files remain available in the new branch when

you move to it

Everyday tasks with Git: Branching Example

// “master” is BEHIND “origin/master”, “featureA” and “featureB”

// “featureB” is BEHIND (specifically, 1 commit) and AHEAD (1 commit) of “origin/master”

// “featureA” is BEHIND (specifically, 1 commit) and AHEAD (2 commits) of “origin/master”

// “origin/master" AHEAD because someone committed before you

Everyday tasks with Git: Checkout

● Checkout a certain project version○ There is no concept for updating○ Git saves project status, so you could “drive” the project

to older versions or a new version (physically copies the files from the commit to the stage and working directory)

○ git log // logging to look for the commit_id necessary○ git checkout // jump to the last commit in the current branch○ git checkout HEAD^^○ git checkout my_new_branch // jump to the last commit in the current

branch (change of branch)○ git checkout -b my_new_branch // jump (if it doesn't exist, create it)

○ git checkout -f master // jump forcing to override the local changes○ git checkout commit_id // jump to the commit with “commit_id” in the

current branch

Everyday tasks with Git: Checkout Example

Everyday tasks with Git: More Checkout

In branch “master”:git checkout experiment

In branch “experiment”:git checkout master

HEAD points “master”:refs/heads/master

HEAD points “experiment”:refs/heads/experiment

Everyday tasks with Git:Files

● Add and remove○ Git tracks files when added them to INDEX○ When you creates a file, it is NOT TRACKED BY

DEFAULT○ So to track it: git add filepath/filename○ git add . // add any new or modified file/directories○ git add -A // add any new, modified or deleted file/directories○ git add -u // update already tracked files/directories○ git add --force // add any files even they are ignored○ In the same way, if you need to untrack a file: git rm

filepath/filename○ git rm filepath/filename --force // remove physically as well

Everyday tasks with Git:More Files

● Add and remove○ git add -i // interactive version

○ Perfect when you have certain files to not addPerfer staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb

*** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: helpWhat now>


● Move○ git mv test.txt lib○ git mv reader tester // rename directory “reader” to a new directory

called “tester”○ Moving with Git, we notify two things: the file was deleted,

and the file was created in the new place○ If you move by SO, Git haven't any notice about this

movement: it finds this file deleted, and this new one in another path

○ Another way to do the same: git add and git rm○ REMEMBER: You only could move files with Git,

tracked with Git, logically!


● Rename○ git mv test.txt new_test.txt○ git mv reader tester // rename directory “reader” to a new directory

called “tester”○ git mv reader tester --force // rename directory “reader” to a new

directory called “tester”, forcing the overwriting

Everyday tasks with Git:Commits

● Do a commit○ 1 OR MORE LOCAL CHANGES○ git status // current status of the working copy○ Then, before to commit, ask Git to keep track the new or

modified files with git add . (this action add the content to the index)

○ To commit, it's always necessary to set a comment: using a text editor (by default) or directly as an option

○ git commit -a -m 'GRB: Initial commit'

Everyday tasks with Git:Commit Example

Everyday tasks with Git: Reverting

● Revert changes in the working copy○ If you had a mistake, DON'T WORRY!○ If you create files which you will not want to commit,

discard them using git clean○ touch test01 && git clean --force -d○ If you delete files which you didn't want to delete, check

out them using git checkout ○ rm test.txt && git checkout test.txt○ If you modify files which you didn't want to modify, check

out them using git checkout (back to the last version)○ git checkout -- // revert all changes in your working copy○ gedit test.txt && git checkout -- test.txt // revert for the file "text.txt"

Everyday tasks with Git: More Reverting

● Changes to be committed○ If you had a mistake, DON'T WORRY!○ If you have many local changes to be committed, which

you will not want to commit, undo them using git reset○ git reset HEAD^ // revert all changes, and unstage, to the previous

version for HEAD (working copy is not updated)○ git reset --soft // revert all changes to back last (the working copy is not

updated)○ git reset --soft HEAD^^○ git reset --hard // revert all changes to back last version (any change in

the index is lost, and working copy is updated, losing your current work)○ git reset --hard HEAD^^○ If a file name is given, it works as git checkout for that file○ git reset test.txt // revert all changes, and unstage, to the last version

for the file "test.txt" (the working copy is not updated)

Everyday tasks with Git: Reset Example

Everyday tasks with Git: More Reverting

● Changes to be committed○ The same for a specific file○ If a file name is given, it works as git checkout for that file○ git reset test.txt // revert all changes, and unstage, the file "test.txt"

(working copy is not updated)○ git reset -- test.txt // revert all changes, and unstage, the file "test.txt"

(working copy is updated)

Git Recipes:Undo last commits

1. Review your working copy status2. Review your command history with reflog3. Reset hard with the index in which you want to get backNote: IRREVERSIBLE OPERATION! (any change is LOST)

Everyday tasks with Git:Pulling or Fetching?

● Get the changes○ There are two options: to PULL or FETCH○ Any of them allows you to sync your working copy with the

remote repository○ PULLING is the same than FETCHING, but additionally

makes a MERGING (try to merge any change)○ So automatically WITH PULLING YOUR WORKING

COPY COULD CHANGE WITHOUT YOUR CONTROL, AND LOST YOUR CURRENT WORK!!

○ git checkout // jump to the last commit in the current branch○ git pull // get information from the cloned remote repository○ Anyway, fetching is highly recommend instead of

pulling○ git fetch // get information from the cloned remote repository○ git fetch origin // get information from the remote repository pointed by

the alias called “origin”

Everyday tasks with Git:Fetching Example

Working copy


Local repository AHEAD AND BEHIND 2 COMMITS BOTH!

MERGE NON-FF!!!

Everyday tasks with Git:Pushing

● Send your changes○ When you want to share your changes○ 1 OR MORE COMMITS to remote repository○ git push // send information to the cloned remote repository and the current

branch○ git push origin my_new_branch // the same for the remote

repository called “origin” and the branch “my_new_branch”○ If you get an error saying that the “remote repository can't

fast-forward the branch”, probably you were behind○ LESSON: always do a FETCH+MERGE before PUSH to

be at the same level○ If anyone would push at the same time, the last one was

rejected (that person should get his changes, and then try to push again)

Everyday tasks with Git:Pushing Example

2 COMMITS BEHIND,1 COMMIT AHEAD

Everyday tasks with Git:Pushing Example

Everyday tasks with Git: Commit Reverting

● Undo or delete a commit○ If you had a mistake, DON'T WORRY!○ Once you push your commit, you can NOT delete the

revision○ If you make commits which you didn't want to commit,

AND SOMEONE PULLED, undo them using git revert○ Reverting will CREATE A NEW COMMIT○ git log // logging to look for the commit_id necessary○ git revert // revert the last commit (signaled by HEAD)○ git revert HEAD○ git revert commit_id // revert the commit with "commit_id"○ Once reverted, push the new commit to the remote

repository, if it's necessary

Everyday tasks with Git: Merging

● Make a merge○ Merge is to combine the changes○ 1 OR MORE COMMITS○ It's possible merge any branch into the current branch○ A new commit is created, which incorporates the changes

from other commits○ Automatically Git knows how to merge those changes

between branches (three-way-merge way)○ git checkout develop // jump to the last commit in the branch "develop"○ git fetch○ git merge origin/develop○ Git allows to merge any merge conflict, if it knows how to

resolve○ git checkout -m my_new_branch // jump to the last commit, and

automatically resolve any merge conflict

Everyday tasks with Git: More Merging

● Merge conflicts○ Many people modifying the same files○ Git wouldn't know how to merge those changes○ As SVN, in these cases, Git inserts standard merge

conflict markers into files, for manual resolving by programmers later

○ SOLUTION: modify the affected files manually, or using tools such as mergetool, and later add and commit

Everyday tasks with Git: FF Merging

● Fast Forward○ Special case of merging○ FF is the situation in which is only necessary to move the

HEAD pointer to new position in the remote branch○ Git resolves this situation for us, trying to make this

merging process: AUTOMATICALLY, with git merge or git pull

Everyday tasks with Git: FF Example

Everyday tasks with Git: Non-FF Merging

● Resolve a Non-Fast Forward Merging○ Special case of merging○ A Non-FF is the situation in which is necessary to create

new commits, and move the HEAD pointer to new position in the remote branch

○ Sometimes remote repository reject the push, normally because of there are many changes in the same part of the same file/files in both branches: CONFLICTS

○ Git pauses the merging process, and waits for your resolution

○ DON'T PANIC: this situation could be extremely easy to fix○ Use git status to know what files needs merge

Everyday tasks with Git: Non-FF Merging

In branch “master”:git merge origin/master

// A new commit is created in “master” with both branches merged (“72bbc” in this case), and “master” is now AHEAD (1 commit) of “origin/master”

Pointer is moved to the last commit: git push

Everyday tasks with Git: More Merging

● Using mergetool○ GUI or no-GUI tool○ apt-get install meld○ git config --global merge.tool meld○ git mergetool

Everyday tasks with Git:Merging with meld

COMMON ANCESTOR VERSION

CURRENT BRANCH: master

ANOTHER BRANCH: mywork

FINAL RESULT!!

Git Recipes:Upload changes

1. Review your working copy status2. Ask Git to keep track the new or modified files 3. Commit the added files4. Fetch the possible changes from remote repository

5. Resolve possible merging problems6. Push your changes to the remote repository

Index

1. Git Basics




Everyday tasks with Git: Analyzing changes

● See differences between commits○ Git has got a specific internal tool○ git diff // differences (if any) between HEAD and working version○ git diff HEAD // differences (if any) between HEAD and working version○ git diff HEAD^^ // differences (if any) between 2 commits before HEAD

and working version○ git diff HEAD~4..HEAD // differences (if any) between 4 commits before

HEAD and HEAD○ git diff test.txt // differences (if any) on file between HEAD and working

copy version○ git diff HEAD test.txt○ git diff HEAD^^ test.txt○ git diff HEAD~4..HEAD test.txt

Everyday tasks with Git: Diff Example

Everyday tasks with Git: More Analyzing

● Reviewing a commit○ Git allows to review a commit○ git show HEAD // commit logging by HEAD ○ git show HEAD^^○ git show HEAD test.txt // file logging on commit by HEAD ○ git show HEAD^^ test.txt

Everyday tasks with Git: More Analyzing

● Using difftool○ GUI or no-GUI tool○ git config --global diff.tool meld○ git config --global diff.tool kdiff3○ git difftool

Everyday tasks with Git:Analyzing with kdiff3

Everyday tasks with Git:Tagging

● Tag with a friendly name○ Optional feature to use○ Tag is an human readable shortcuts for commit hashes○ Useful when you want to remember a certain version in

the history commit, and find it more easily later ○ Typically, for versions which have been released○ git tag // list available of tags○ git tag -n // list available of tags with their description○ git tag “Version 1.0” // instead of e74g64a21...○ git tag -d tag_id // delete the tag with name “tag_id”○ git tag -v tag_id // show a description for the tag with name “tag_id”

Everyday tasks with Git:More Tagging

Everyday tasks with Git:Rewriting History

● Variable past?○ Git allows to change the commit history○ This issue could be very useful, for example, rewriting

some part of commit history before pushing your changes to a remote repository

○ But BE CAREFUL: YOU ARE CHANGING THE HISTORY, AND YOU COULD AFFECT SOMEONE!!!

○ Specifically, Git hasn't got a change history tool

Everyday tasks with Git:More Rewriting

● Rebase commits○ Modification at several commits level○ Typical use: integrate changes from one branch to another

(alternative for merging) ○ Other uses are to combine several commits into one

commit as base (SQUASHING), reorder commits (REORDERING), select certain commits, etc.

○ git rebase master○ git rebase --onto master 169a6 // rebase since 169a6 (exclusive)○ Anyway, REMEMBER: DON'T REBASE ON COMMITS

WHICH WERE COMMITTED ON PUBLIC REPOSITORY (for example, a team working with a central repository)

○ git rebase --abort // abort the rebasing operation

Everyday tasks with Git: Rebasing Example

// initially, local history is diverged respect "origin" on 1 commit


// initially, in branch "topic" git checkout topic


● Rebase commits interactively○ Git allows to use an interactive version○ git rebase -i HEAD~3 // to change the last three commits, or any of them

in that grouppick f7f3f6d changed my name a bit

pick 310154e updated README formatting and added blame

pick a5f4a0d added cat-file LAST COMMIT!

# Rebase 710f0f8..a5f4a0d onto 710f0f8

#

# Commands:

# p, pick = use commit

# e, edit = use commit, but stop for amending

# s, squash = use commit, but meld into previous commit

#


REORDERING

pick f7f3f6d changed my name a bit


pick a5f4a0d added cat-file





pick a5f4a0d added cat-file

SQUASHING


squash 310154e updated README formatting and added blame

squash a5f4a0d added cat-file

Unified and added to f7f3f6d!!

Reordered, and removed a5f4a0d!!


● Mistakes in previous commits○ Git allows to change the commit history○ git log○ git checkout commit_id // check out into commit with "commit_id"

which there are mistakes○ gedit text.txt○ git add text.txt && git commit --amend // change the commit

message if it's necessary○ git rebase --onto HEAD commit_id master // rebase any commit till

"commit_id" after HEAD using HEAD as base for the branch "master" (SQUASHING)

○ BE CAREFUL: git rebase --onto without the two arguments is equals a RESET HARD!!!

Everyday tasks with Git: Commit Amend Example


● Pick up commits○ Modification at single commits level○ With cherry-picking it's possible to pull single commits

from one branch to another○ This is only possible if the working directory is clean

(any change pending to add and commit) This ○ git log feature○ git checkout master // check out with the branch where you want to

add the commit○ git cherry-pick 97fedac // get the commit necessary, with commit_id

“97fedac”○ Automatically Git merges the given commit into the specific

branch

Everyday tasks with Git: Cherry-Picking Example

// initially, in branch "master" git checkout master

Index

1. Git Basics




Everyday tasks with Git:Logging

● Get some information about commits○ git log // commit history of the current branch○ git log test.txt // commit history of a certain file○ git log --oneline // commit history of the current branch (one line mode)○ git log -n 2 // last two commits of the current branch○ git log HEAD~4..HEAD // commit history of the current branch between

two given commits○ git log --diff-filter=D // show deleted (D) files○ git log --pretty=fuller // commit history of the current branch with all the

information possible○ git log origin/master // commit history of the "master" in remote "origin"○ git reflog // a friendly interface to watch the updates on the current

branch○ git blame test.txt // show file with its modifications, line by line○ gitg --all // gitg showing all branches○ gitk --all // gitk showing all branches

Everyday tasks with Git:Logging with gitk (GUI to review changes)

Everyday tasks with Git:Logging with gitg (GUI to review changes)

Everyday tasks with Git:Logging

● Creating a “contributions” log○ How to know how many commits by user?○ Useful in some cases: to see what kind of impact a

developer has made on the repository, a friendly competition into committing code, etc.

○ git shortlog // show for the current branch○ git shortlog master // show for the branch “master”○ git shortlog --no-merges master –not v1.0.1 // not included

commit with tag “v1.0.1”○ git shortlog -n // show ordering by number of commits○ git shortlog -e // show ordering adding emails○ git shortlog -s // not show the commits messages

Everyday tasks with Git:Optimizing

● Clean to speed up larger repositories○ You could have to do some cleanup○ Check object storage is sane with git fsck○ Clean up the repository and compress files with git gc,

which runs the garbage collector ○ Occasionally, Git automatically runs the command “auto

gc” for cleaning up

Everyday tasks with Git:Searching

● Locate files with a certain text○ git grep hello○ git grep “hello how are you”○ git grep --untracked “hello how are you” // search on tracked and

untracked files○ git grep “hello how are you” *.xml // search on any tracked file with

extension XML○ git grep --untracked “hello how are you” *.xml // search on any

tracked and untracked file with extension XML○ git grep -e “hello” --and -e “how are you”○ git grep --all-match -e “hello” -e “how are you”

Everyday tasks with Git:Stashing

● “Disaster” box○ Simple and useful mechanism for WIP○ When you have work without finishing, and you don't

like to lose it○ Changes RESPECT THE LAST COMMIT are saved

temporally○ git stash

Saved working directory and index state WIP on master: e87b43b bugfix for initialize spot

HEAD is now at e87b43b bugfix for initialize spot

○ git stash list // show list of stashes○ git stash show stash@{#} // show changes for stash with number #○ git stash apply // apply changes for stash with number #

Everyday tasks with Git:Patching

● Create a patch files per commit○ git diff text_modif.txt > patch-test.patch○ git diff text_orig.txt text_modif.txt > patch-test.patch○ git format-patch HEAD○ git format-patch HEAD^^..HEAD○ To apply a patch: git apply (if patch created by git diff) or git

am (if patch created by git format-patch)○ git apply /tmp/patch-test.patch○ git apply --check /tmp/patch-test.patch // simulate the patch apply,

and show possible errors○ git am patch-test.patch

Git Recipes:Bug fixing

1. Clone the repository2. Create a new branch for the bug fix3. Modify the files (source code)4. Commit changes to your branch5. Create a patch6. Send patch to another person or attach it to a bug report (for applying to the other Git repository)Note: Other option is to be remote repository, and anyone could download the branch with the fixing

Questions?

git session-2012-2013

Documents

source files

centralized repository

central repository

repository similar

history remote repository

git protocol

git basics2

svn gitsvn