Git session-2012-2013
-
Upload
jose-manuel-vega-monroy -
Category
Documents
-
view
198 -
download
0
Transcript of 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)
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.
|-- COMMIT_EDITMSG
|-- FETCH_HEAD
|-- HEAD
|-- ORIG_HEAD
|-- branches
|-- config
|-- description
|-- hooks
| |-- applypatch-msg
| |-- commit-msg
| |-- post-commit
| |-- post-receive
| |-- post-update
| |-- pre-applypatch
| |-- pre-commit
| |-- pre-rebase
| |-- prepare-commit-msg
| `-- update
|-- index
|-- info
| `-- exclude
|-- logs
| |-- HEAD
| `-- refs
|-- objects
`-- refs
|-- heads
|-- remotes
|-- stash
`-- tags
| |-- prepare-commit-msg| `-- update|-- index|-- info| `-- exclude|-- logs| |-- HEAD| `-- refs|-- objects`-- refs |-- heads |-- remotes |-- stash `-- tags
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
2. Working with Git: Novice
3. Working with Git: Advanced
4. Working with Git: Utilities
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
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
Everyday tasks with Git: More Starting!
● 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
Everyday tasks with Git: More Starting!
● 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
Everyday tasks with Git: More Starting!
● Help me!○ Git always offers you help○ git help○ git command_name --help // man page for the command
“command_name”
Everyday tasks with Git: More Starting!
● 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
Everyday tasks with Git: More Branching
● 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
Everyday tasks with Git: More Branching
● 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
Everyday tasks with Git: More Branching
● 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: 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>
Everyday tasks with Git:More Files
● 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!
Everyday tasks with Git:More Files
● 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: 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
Everyday tasks with Git:Fetching Example
Everyday tasks with Git:Fetching Example
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
2. Working with Git: Novice
3. Working with Git: Advanced
4. Working with Git: Utilities
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
Everyday tasks with Git: Rebasing Example
// initially, in branch "topic" git checkout topic
Everyday tasks with Git: Rebasing Example
// initially, in branch "topic" git checkout topic
Everyday tasks with Git:More Rewriting
● 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
#
Everyday tasks with Git: Rebasing Example
REORDERING
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
pick 310154e updated README formatting and added blame
pick f7f3f6d changed my name a bit
pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
SQUASHING
pick f7f3f6d changed my name a bit
squash 310154e updated README formatting and added blame
squash a5f4a0d added cat-file
Unified and added to f7f3f6d!!
Reordered, and removed a5f4a0d!!
Everyday tasks with Git:More Rewriting
● 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
Everyday tasks with Git:More Rewriting
● 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
2. Working with Git: Novice
3. Working with Git: Advanced
4. Working with Git: Utilities
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?