Git intermediate workshop slides v1.4

OptionFactory
Git, beyond the basics
intermediate level workshop

About OptionFactory
Main activities
● Software development & consultancy
● Continuous Integration & Delivery
● Training & coaching
Key competences
● Java, Javascript, C++, Go, Erlang and more
● Secure Software Development Lifecycle
● Lean Software Development
● Re-engineering
Core domains
● High Availability and High Performance systems
● Application security
● Telcos, finance, insurance and security sensitive domains
● Startups, new markets and high uncertainty domains

Goals
If that doesn’t fix it, git.txt
contains the phone number of a
friend of mine who understands
git. Just wait through a few
minutes of “It’s really pretty
simple, just think of branches
as…” and eventually you’ll learn
the commands that will fix
everything.
HTTP://XKCD.COM/1597/
“

Goals (II)
No, improvising is wonderful.
But, the thing is that you cannot
improvise unless you know
exactly what you're doing.
Christopher Walken
“
”

Establishing a common base
● Participants’
○ background
○ VCS tools known
○ level of experience
○ expectations

Version control basic idea
● Frequent:
○ Do some work
○ Save and store away a copy of your work at a certain point in time
○ Give each copy a name for future reference
● Once in a while:
○ Be able to go “back in time” to see what changed
○ Possibly discard recent work and start over from a previous point
○ Communicate your changes to others
Analogy: Savegame

Story of a file
● Corso Git Trieste - materiale di presentazione v1.1

Story of a file
● Git Workshop slides v1.2

Story of a file
● Git Workshop slides v1.2 - DS

Story of a file
● Git Workshop slides v1.2 - RF

Story of a file
● Git Workshop slides v1.2 - DS + FD

Story of a file

Story of a file
Are these all the same file? What’s the sequence?

What we want to capture
Most of the times saving a single file is not enough - information is often
distributed and correlated. In computer programs, changes to one file are often
strongly related to changes in other files - to the point our program breaks down
if we take into account only the changes from one file.
What we are really interested in (each time) is:
● what changed (files)
● where did I start from (previous version)
● who changed it (useful when multiple people collaborate)
● when it changed
● why it changed
● some kind of handle to reference each of such changes

Starting up
● setup your global git environment
○ git config --global user.name “Mario Rossi”
○ git config --global user.email “mrossi@example.com”
● initialize (i.e. create) your first repository
○ mkdir myfirstrepo
○ cd myfirstrepo
○ git init

Creating a commit
1. Create / edit files on your working copy (your local filesystem)
2. Mark your changes for inclusion by copying them in the staging area
3. Create a new commit, providing the missing (meta) data
● What goes in the commit comes from:
○ whatever you put in the staging area (the “what”)
○ your git configuration:
■ your name & email (the “who”)
○ the (git) environment :
■ the current date (the “when”)
■ the commit you started working from (the “where”)
○ the message you specify (the “why”)
○ the commit itself (commit id, the “handle”)

checkout/reset (file)
Checkout <file> Checkout <ref> -- <file> Reset <file>
Effect on graph
shape
None None None
Effect on
Staging Area
None Overwritten with version from graph Overwritten with version from
graph
Effect on
working copy
Overwrite with version from
staging area
Overwritten with version from graph None
Staging area
Working Copy Graph
add <file> com
m
it
reset<file>
checkout <ref> -- <file>
checkout <file>

Version control landscape
Git Mercurial (HG) SVN ClearCase
Transaction unit Commit Commit Commit File
Storage model Snapshot Delta Delta ?
Model Distributed (clone) Distributed (clone) Centralized
(checkout)
Centralized
(checkout)
Transaction id Hash Hash (local
sequence)
Global sequence Path + per-branch
sequence
Concurrency
model
Merge/Rebase
(graph)
Merge (graph) Merge on commit
(linear)
Pessimistic
locking + merge
(linear)
Rename / move
tracking
No (heuristic) Yes Yes Yes*

Centralized vs distributed (I)

Centralized vs Distributed (II)
Centralized Distributed
Instances Single, mandatory
Every istance is equal. “Central authority” is a
convention, not a necessity
Transaction id Centrally assigned Anyone must be able to assign it
The Truth™ One and only
“Luke, you're going to find that many of the truths we cling
to depend greatly on our own point of view.” _ Obi-Wan
Kenobi

Centralized vs Distributed (III)
Centralized Distributed
Isolation None, each transaction is “public” Many Sandboxes environments
Speed per
commit
Low, every transaction required
network communication
Fast, changes are on the local filesystem.
Conflicts Pain Manageable pain

The git graph
● Each branch tracks either (or both):
○ alternate “timelines”
○ parallel work

Showing the Git graph
● Some examples:
○ git log --graph --decorate --all --abbrev-commit --pretty=oneline
○ git log --graph --decorate --all --abbrev-commit --format=format:'%C(bold
blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C
(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C
(dim white)- %an%C(reset)'
● Found a combination you like? keep it as an alias:
○ git config --global alias.graph "log --graph --decorate --all --abbrev-
commit --pretty=oneline"

Inside a commit
● id
● parent id(s)
● timestamp
● author (& committer)
● message
● content
○ filesystem state
● NOT part of a commit
○ branch
○ tags

References & reachability
● A reference is just a named pointer to a commit in the graph
● Every commit, to be reachable, must be referenced:
○ directly (by a ref)
○ indirectly (by a reachable descendant, pointing to its parent)
● Bad parenting advisory:
○ Parent commits do not know about their children
○ You can’t navigate forward in time through the graph

references: Branches
● a “branch” identifies a sequence of commits, tracing a workflow
● “master” is by convention the project main line
● A branch ref points to a commit in the graph, and represents a pointer to
such commit. It is not directly related to working copy or staging area
● Any number of branches can point to the same commit, they are all
independent

references: HEAD
● HEAD is a special reference. It can either point to a commit or a branch,
and represents where we are in the graph
● The commit it points to (directly or indirectly) is used for comparison
against the staging area
● When HEAD points to a Branch reference, that branch is “current”, and will
move ahead on commit
● When HEAD points directly to a commit, we are in the “detached HEAD”
state
○ even if there are branches referencing that same commit

Checkout/Reset/Revert (ref)
Checkout <ref> Reset <ref> Revert <ref>
Moves HEAD only “current” Branch “current” Branch
Effect on graph shape None potentially leaves back “dead”
nodes
Creates new node
Effect on Staging Area Fails if dirty* overwritten with --mixed (default)
or --hard
Fails if dirty
Effect on working
Copy
Fails if dirty overwritten only with --hard Attempts merge, fail if
not possible

Alternate (time)lines
● Creating alternate lines of work
○ branch
● Navigating the graph
○ checkout
○ reset
● “Crossing the streams” and other weird stuff
○ merging
○ git merge-based <ref> <ref>
○ git config --global merge.conflictstyle diff3 (merge)
○ git merge -Xignore-all-space (-Xignore-space-change)
○ rebasing
○ cherry-picking

references: Tags
● Lightweight Tags are similar to branches (a name attached to a specific
commit), but they are not meant to move
● Annotated Tags also contain an id, timestamp, author and a message on
top of that
● Therefore, annotated tags can be signed

● remotes: names pointer to a remote repository
○ origin is the one you cloned from (just another convention)
● remote branches
○ Remote references differ from branches (refs/heads references) mainly in that they’re
considered read-only. You can git checkout to one, but Git won’t point HEAD at one, so
you’ll never update it with a commit command. Git manages them as bookmarks to the last
known state of where those branches were on those servers.
https://git-scm.com/book/it/v2/Git-Internals-Git-References
● tracking branches
○ local branches bound to a remote branch
○ git checkout --track (remote)/(branch)
○ tracks your work on that branch to allow sync
Remotes, refs, tracking branches

Synchronization & collaboration
● clone
● push
● fetch
● pull (fetch+merge o fetch+rebase)

Collaborative workflow
● commit message
● approaches (not exclusive)
○ based on merge
○ based on rebase

http://zeroturnaround.com/wp-content/uploads/2016/02/Git-Cheat-Sheet.png

.gitignore
● Ignores untracked files in the folder or subfolders
● useful to ignore contents generated on the fly, or custom settings files (e.
g.: IDE configuration for the project)
● Useful templates:
○ https://github.com/github/gitignore
○ https://help.github.com/articles/ignoring-files/

git as a service
● github, gitlab, bitbucket
● basic concepts mapping
● Authorization models
● “Fork” and “Pull Request” implementations
○ pull request - “Please, take my changes”

Resources
■ Good base: http://www.learnenough.com/git-tutorial
■ Visualizing Git Concepts with D3: https://onlywei.github.io/explain-git-with-d3/
■ Think like a git: http://think-like-a-git.net/epic.html
■ Git workflows comparison: https://www.atlassian.com/git/tutorials/comparing-workflows
■ Cache your passwords: https://help.github.com/articles/caching-your-github-password-in-git/
■ Git-scm book (https://git-scm.com/book/en/v2), in particular:
● https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
● https://git-scm.com/book/en/v2/Git-Tools-Reset-Demystified
● https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
■ Some open source projects to visualize git graphs:
● https://github.com/FredrikNoren/ungit/blob/master/README.md
● https://github.com/Readify/GitViz
● https://github.com/Haacked/SeeGit
■ Always funny to watch: http://gource.io/
■ Nice course: http://gitimmersion.com/index.html
■ Nice tool to create demo graphs: http://gitgraphjs.com/
■ Git cheat sheet: http://zeroturnaround.com/rebellabs/git-commands-and-best-practices-cheat-sheet/
■ Interesting videos:
● Introduction to Git with Scott Chacon of GitHub: https://www.youtube.com/watch?v=ZDR433b0HJY
● Brilliant representation of the graph: https://www.youtube.com/watch?v=1ffBJ4sVUb4

Git intermediate workshop slides v1.4

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (8)

Similaire à Git intermediate workshop slides v1.4

Similaire à Git intermediate workshop slides v1.4 (20)

Dernier

Dernier (20)

Git intermediate workshop slides v1.4