This document provides an overview of using Git like a pro. It begins with introducing the author and stating goals of increasing Git understanding, solving cumbersome situations, producing cleaner Git history, and having fun. It then covers key Git concepts like objects, references, branches, HEAD, merging vs rebasing, interactive rebasing, rerere, and how to use reset, reflog, and bisect commands to troubleshoot issues. The document emphasizes hands-on learning through examples and encourages experimenting in the provided Gitlab repository.

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”
@beni0888
https://www.linkedin.com/in/jesusmiguelbenito/

3. 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!

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

5. 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.

6. What is a git branch?

7. 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

8. 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.

10. 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

11. Synchronizing branches

12. Branches out-of-sync

13. 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.

14. Merge: This is a mess!!

15. Rebase
$> git rebase master

16. 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

17. 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

18. 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

21. 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`

22. 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.

23. 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

24. 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

25. Sometimes things can go wrong…

26. 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

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

28. 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

29. 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>

30. What really happens when rebasing?

31. 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.

32. 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.

33. 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.

34. 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

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

36. 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

38. 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

39. Looking for errors

40. 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.

41. 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

42. 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

43. 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!

44. 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'

45. 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.

46. 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

47. 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.

49. 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’
…

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

52. Thank you!