This document provides an overview of using Git like a pro. It discusses Git fundamentals like objects, references and branches. It also covers advanced topics such as rebasing, reflogs, resetting and bisecting to find errors. The goals are to increase understanding of Git internals, solve cumbersome situations, produce cleaner histories and have fun.

1. USING GIT LIKE A PRO
JESÚS MIGUEL BENITO CALZADA
EDD - 27/10/2018

2. About me
git config --global user.name “Jesús Miguel Benito Calzada”
git config --global user.email “beni0888@hotmail.com”

3. About me
git config --global user.name “Jesús Miguel Benito Calzada”
git config --global user.email “beni0888@hotmail.com”
@beni0888
https://www.linkedin.com/in/jesusmiguelbenito/

4. Goals
 Increase our understanding of Git internals
 Get the knowledge to solve cumbersome situations
 Be able to produce a better (cleaner, coherent) Git history
 Have fun!

6. Git directory's main items
 HEAD: a reference to the commit we have currently checked
out.
 Config: file that stores repo’s configuration.
 Objects: directory containing git objects’ database.
 Refs: directory that contains all repo’s references: branches
(locals and remotes) and tags.
 Some other files and folders used for different purposes.

7. Git objects
The Git object database store four different
object types:
 Blob
 Tree
 Commit
 Tag

8. Git objects

9. Git cat-file
 Shows the information about an object in the repository:
-t: show type
-p: shows object content
-s: object size
> git cat-file (-t|-p|-s) <object>

10. Git objects - Blob
 Stores the contents of a file in compressed form.
 Meaningless by its own, does not contain any reference to
the file which it refers to.

11. Git objects - Tree
 Equivalent to a ‘directory’ in the file system.
 Contains a list of Blobs (along with the files they refer to)
and other Tree objects.

12. Git objects - Commit
 Snapshot image of a particular directory tree.
 Additional metadata:
 Timestamp
 Author
 Committer
 Log message
 Identities of parent commits

13. Git objects - Tag

14. Git objects – Tag
 Annotated tags.
 A container that holds a reference to an object (usually a
commit).
 Metadata (tag name, tagger and description).

15. References
 A reference is a “pointer” to a commit.
 It holds the SHA-1 hash of a commit.
 Allows us to refer to commits in a human-friendly way.
 Stored in files under .git/refs directory.

16. What is a git branch?

17. What is a git branch?
 It is just a reference to a commit!
 Stored in files under .git/refs/heads (.git/refs/remotes)
 Tags are also references under .git/refs/tags

18. References – HEAD
 HEAD is a special reference that
points to the commit you have
currently checked out.
 Stored in .git/HEAD file.
 It usually points to another
reference instead of a commit!
 When it points to a commit, we said it
is in a detached state.

19. References – HEAD

21. Tip
 You can just do as follows:
 After creating a local branch, we need to provide its upstream
before pushing.
> git checkout -b my-branch-with-a-long-name
> git push
fatal: The current branch my-branch-with-a-long-name has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin my-branch-with-a-long-name
> git push origin HEAD

22. Specifying revisions
 SHA-1, short SHA-1
 Any valid reference: branch, tag, HEAD
 Reflog short names: HEAD@{5}, @5… (we will see later)
 Ancestry references: HEAD^, HEAD~
 Commit ranges
 Double dot: <ref-A>..<ref-B>
 Exclude commits reachable from ref: ~<ref>, --not <ref>
 Multiple points: <ref-A> <ref-B> ~<ref-C>
 Triple dots: <ref-A>…<ref-B> (Shows the commits reachable by either
of two references but not by both of them.
There are several ways we can refer to a commit/revision:

23. Ancestry references
 A = = A^0 = A~0
 B = A^ = A^1 = A~ = A~1
 C = = A^2
 D = A^^ = A^1^1 = B~ = A~2
 E = B^2 = A^^2
 F = B^3 = A^^3 = A^2^ = C~
<rev>^<n> = The <n>th parent of rev.
<rev>~<n> = The <n>th generation ancestor of <rev>, following only the first
parents.

24. Ancestry references
A^0 = A~0
A^ = A^1 = A~ = A~1
A^^ = A^1^1 = A~2 A^2^ = A^^3 = B^3
A^2
A^^2 = A~^2 = B^2

25. Git rev-parse
 It is a “magic command” used by many other commands to
do different things.
 Convert a commit reference to a real SHA-1:
> git rev-parse <ref>
 Obtain current branch name:
> git rev-parse --abbrev-ref HEAD
 Obtain relative path to go back to repo’s root:
> git rev-parse --show-cdup

27. Tip: rev-parse
 Create an useful alias to go back to the repo’s root
directory, it does not matter how deep you are in the
tree:
$> alias groot = “cd `git rev-parse --show-cdup || pwd`”

28. Synchronizing branches

29. Branches out-of-sync

30. Merge
 $> git merge master feature
 The most common and easy way of synchronization.
 Produces ugly merge commits.
 Keeps the context of the synchronization.
 Branch history can be difficult to follow.

31. Merge: This is a mess!!

32. Rebase
$> git rebase master

33. Rebase
 Rewrites all feature branch’s commits on top of master branch.
 Much cleaner project history:
 Avoid ugly merge commits.
 Perfectly linear project history.
 Some drawbacks:
 It rewrites the history! Generate new different commits, with different
SHA-1.
 Loses the context of synchronization provided by a merge commit.
 Golden rule: never use it on public branches!!
 Merging vs Rebasing

34. Lab
 Clone repo: https://github.com/beni0888/gitlikeapro
 Execute a rebase:
 Checkout rebase-no-conflicts
 Rebase it onto rebase-base
 Tip: git log rebase-base…rebase-no-conflicts (show divergent
commits)
 Execute a rebase with conflicts:
 Checkout rebase-with-conflicts
 Rebase it onto rebase-base
 Resolve conflicts and finish rebase

35. Interactive rebase
git checkout feature
git rebase (--interactive | -i) <commit-ref>
 Allows to edit the history from a commit on.
 It opens an editor showing the list of commits that are going to
be replayed, and allows to perform certain actions on them:
 Join commits: squash, fixup
 Edit commit message: reword
 Edit commit content: edit
 Remove commit: drop
 Reorder commits: just change commit’s order in the editor

37. Rebase Tip
 Returns the SHA-1 of the base commit of feature branch.
 Useful to interactively rebase the whole branch.
git merge-base master feature
git rebase -i `git merge-base master feature`

38. Lab
 Execute a interactive rebase:
 Checkout rebase-base branch.
 You can get its origin commit with git merge-base master head
 Do some experimentation: join commits, edit, reorder...
 Be creative!
 Finish the rebase operation and check the results.

39. More on rebase
 Git does not allow to execute git pull on a dirty working
tree.
 This way git will stash your changes, update your branch
and unstash your changes again.
 Nice but, wouldn’t be possible to do all this in just one
step??
git fetch
git rebase --autostash

41. Tip: autostash
 Everytime you run git pull, it will perform a rebase under
the hood.
 And everytime git rebase is executed, it will run with
autostash option.
 Update your branch in just one step, even if you are in
a dirty working tree!
git config --global rebase.autostash true
git config --global pull.rebase true

42. Rebase - Squash & Fixup
 Squash:
 Join multiple commits into one.
 Every commit is meaningful by itsown.
 By default git will concatenate original commits’ messages.
 Fixup:
 Melt commit into the previous one (the same as squash).
 Semantically, the commit is a fix to the previous one.
 By default git will only keep the first commit’s message.

43. Rebase - Squash & Fixup

45. Rebase: Squash & Fixup
 Mark for squash/fixup at commit time, any existent
commit.
 Use --autosquash option with interactive rebase.
 Let the magic happens 
git commit --squash <commit-ref>
git commit --fixup <commit-ref>
git rebase -i --autosquash <base-commit-ref>

46. Lab
 Exercise git commit --squash and --fixup options:
 Checkout rebase-base
 Add a new commit with --squash option, selecting as the squash target
some old commit (not the last one).
 Repeat the previous operation but with --fixup option.
 Execute an interactive rebase with --autosquash option.
 Check git log after finish the rebase operation to check the results.

47. Rerere
 Stands for Reuse Recorded Resolution.
 It is kind of machine learning mechanism.
 Learns from your previous decisions on conflicts resolution.
 Apply them automatically reducing the number of manual
interventions.
 Warning! If you do it wrong, it will learn also…
git config --global rerere.enabled 1

48. Lab
 Run git config rerere.enabled 1
 Checkout rerere-with-conflicts.
 Run a rebase onto rerere-base.
 Solve conflicts and finish the rebase.
 Undo rebase: git reset --hard ORIG_HEAD
 Run the rebase again and see what happens

49. Sometimes things can go wrong…

50. Git reset to the rescue!
 Versatile and powerful command for undoing changes.
 Similar to checkout in some aspects.
 Potentially dangerous: destructive operation.
 It allows to:
 Undo changes.
 Unstage files.
git reset

51. Reset
git reset [--soft|--mixed|--hard] C

52. Reset main modes
 Soft:
 Keep undone changes on the index.
 Mixed:
 Default mode, keep undone changes in the working tree, but
without staging them (out of the index).
 Hard:
 Totally removes the undone changes, they are not keep neither in
the index, nor in the working tree.
 Use it with care!!
 Great explanation in stackoverflow

53. Reset vs Revert
 Revert is a safe operation, it takes a commit and generates
a new commit which inverses the specified commit.
 Revert add a new commit to the history, but does not modify
the existent ones.
 Reset rewrites the history to make the branch match the
state of an specific commit.
 Reset vs Revert vs Checkout
git revert <commit-ref>

54. What really happens when rebasing?

55. What really happens when rebasing?

56. What really happens when rebasing?
 New commits are generated at the tip of the target branch.
 But the original old commits are still available in the repo.
 Although they are unreachable (there is no reference pointing
to them).

57. Reflog
 Reference logs, or "reflogs", record when the tips of branches
and other references were updated in the local repository.
 Remember: a reference is a pointer to a commit.
 Tracks refs updates up to 90 days by default.
 It allows us to recover from errors by accessing to
“unreachable commits”.
 Subcommands: show, expire and delete.

58. Reflog subcommands
 Show:
Show the log for a reference, or all reference (--all option).
 Expire:
Prunes older reflog entries, rarely used by end users.
 Delete:
Removes single entries from the log, typically not used by end users
neither.

59. Reflog - show
 Shows the reflog of the HEAD ref.
git reflog
git reflog show HEAD
f90e666 (HEAD -> master) HEAD@{0}: checkout: moving from branch to master
d92a3b7 (branch) HEAD@{1}: rebase -i (finish): returning to refs/heads/branch
d92a3b7 (branch) HEAD@{2}: rebase -i (start): checkout 19e164a71d87ffa0902c71e92da9f0b61bcc858f
d92a3b7 (branch) HEAD@{3}: rebase -i (finish): returning to refs/heads/branch
d92a3b7 (branch) HEAD@{4}: rebase -i (pick): BRANCH - Add e
da961c4 HEAD@{5}: rebase -i (pick): BRANCH - Add d
5eeef42 HEAD@{6}: rebase -i (fixup): BRANCH - Add c
84d25d0 HEAD@{7}: rebase -i (start): checkout 19e164a71d87ffa0902c71e92da9f0b61bcc858f

60. Reflog - show
 Shows the reflogs for all references
git reflog show --all
git reflog stash
 Reflog also tracks the stash references.

61. Undoing a rebase: reflog + reset
1. Look in the reflog for the commit at the tip of the branch
at the moment prior to the rebase.
2. Git reset --hard to that commit
> git reflog
1544114 (HEAD -> feature) HEAD@{0}: rebase finished: returning to refs/heads/feature
1544114 (HEAD -> feature) HEAD@{1}: rebase: Add bar
3b021d4 HEAD@{2}: rebase: Add foo
d92a3b7 (master) HEAD@{3}: rebase: checkout master
bf12c54 HEAD@{4}: commit: Add bar
e99a22b HEAD@{5}: commit: Add foo
…
> git reset --hard HEAD@{4}
HEAD before rebase

63. Undoing changes: ORIG_HEAD
 ORIG_HEAD is a special reference that stores the previous state
of HEAD. It is set by commands that have possibly dangerous
behaviour (rebase, merge, reset, etc), to be able to easily
revert them.
 Undoing a rebase, reset, merge:
git reset --hard ORIG_HEAD

64. Looking for errors

65. Bisect
 Sometimes you discover that a bug has been introduced in
your code base, but you do not know when it happened.
 The bisect command does a binary search through your
commit history to help you identify as quickly as possible
which commit introduced an issue.
 It allows to identify the commit that introduced the issue,
through a large range of commits, in just a few steps.

66. Bisect
 First, you have to indicate git to start bisecting your history.
 Then you indicate that the current commit is “bad”, or provide
a reference to a previous commit you know is bad.
 And you provide the commit with the last good state known.
 Or just in one command:
> git bisect start
> git bisect bad [<commit-ref>]
> git bisect good v1.2.6-rc
> git bisect start HEAD v1.2.6-rc

67. Bisect
 After that, git will check out the commit in the middle of
the provided range, so you can test it.
 Git will figure out the number of revisions left to test
before finding the target commit.
Bisecting: 2 revisions left to test after this (roughly 1 step)
[da961c4e9813bbc92c308e4487ef527aa25f3bc7] Foo commit message

68. Bisect
 After testing the commit, you should inform git whether it is
”good” or “bad” with git bisect (good|bad) commands.
 Git will narrow down the range of remaining revisions, and
will repeat the same process until the commit which
introduced the breakage is found.
 You can skip testing a commit with bisect skip subcommand.
d92a3b789d3e5e7fcee880b106bb6d0d9694f58b is the first bad commit
commit d92a3b789d3e5e7fcee880b106bb6d0d9694f58b
Author: Jesús Miguel Benito Calzada beni0888@hotmail.com
Date: Thu Oct 4 18:49:17 2018 +0200
Added a really cool feature!

69. Bisect
 You should finish the process with bisect reset command,
to cleanup the bisection state and return to the original
HEAD.
> git bisect reset
Previous HEAD position was d92a3b7... Foo commit message
Switched to branch 'feature'

70. Lab
 Checkout bisect branch
 File.txt contains several lines with the text “EDD rocks!”, each
one added by a different commit, but one line contains a typo:
“EED” instead of ”EDD”.
 Make use of bisect to identify the commit which introduced the
line with a typo.
 Tip: use the commad grep EED file.txt to check if the commit
is wrong.

71. Bisect: let’s automate!
 This is a really manual error-prone process, right?
 Bisect provides a run subcommand that allows us to run a
script to determine whether the commit is good or bad.
 The script must exit with 0 if the commit is good, or
whatever code between 1 and 127 (except 125, used to
skip) for a bad commit.
 You can for example run your test suite to check your
commits.
> git bisect start HEAD v2.1.0-rc
> git bisect run vendor/bin/phpunit
> git bisect reset

72. Lab
 Checkout bisect-run branch.
 Prerequisites:
 You need to have PHP (version >= 5) installed on your computer.
 You need to have composer installed globally, or download its phar from
https://getcomposer.org/download/.
 Run composer install (or ./comporser.phar install).
 The current branch’s test suite has a failing test, and you have to
find the commit that introduce it.
 Make use of bisect run to find the commit which introduced the
error:
 Tip: use vendor/bin/phpunit as script for bisect run.

73. Bisect: alternative terms
 Bisect can be used for more things than just finding the
commit which introduced a bug.
 It provides alternatives terms to good/bad in order to
avoid confusion:
 old/new: are equivalent to good/bad, once you start using them,
you cannot mix them up.
 Custom terms: you can use your own custom terms just by
providing them with --term-{old,good}=<term> and --term-
{new,bad}=<term>

75. Oh-my-zsh git plugin
 Oh-my-zsh comes with a really handy git plugin that saves
us to write a lot: https://github.com/robbyrussell/oh-my-
zsh/wiki/Plugin:git
g=git
ga='git add’
gaa='git add --all’
gap='git apply’
gapa='git add --patch’
gau='git add --update’
gb='git branch’
gba='git branch -a’
gbd='git branch -d’
gbda='git branch --no-color --merged | command grep -vE
"^(*|s*(master|develop|dev)s*$)" | command xargs -n 1 git branch -d’
gbl='git blame -b -w’
…

77. https://goo.gl/forms/mVfvSBHRTmOMSeDG2

78. Thank you!