Git essentials

Don't be a git
The essentials you should know
about git to use correctly
Otto Kekäläinen
Vincit Teatime 11.11.2015
Tampere,Finland

@ottokekalainen
●
15+ years in open source
●
technology & business & advocacy
●
development with git since 2010

Git / t/ɡɪ
”A silly,incompetent,stupid,
annoying or childish person.”
http://en.wiktionary.org/wiki/git

"I'm an egotistical bastard,so I
name all my projects after myself.
First Linux,now Git”
Linus Torvalds,PC World.2012-07-14

Linus needed a new source code revision manager for
Linux,and none of the available options in 2005 where
good enough,so he wrote his own in.
Kernel 2.6.12 was the first release managed by Git and
version 1.0 of Git was released in December 2005.

Git popularity according to OpenHub.net

Git popularity according to Google Trends
git
svn

...but adoption would be faster if it was
not so difficult to use.
Originally Linus did not intend end users to use Git
directly,instead he tried to delegate to somebody
else the task of making the actual command line
interface. We are still waiting for it...
Luckily Git has been simplified and documentation
has improved over time,but some Git commands
still refer to Git internals that are difficult to grasp.
E.g. git-push: Update remote refs along with
associated objects.

Git might feel difficult at first,
but once you learn it, you never
want to go back to anything less
flexible and powerful.

First obstacle: same terms with different meanings

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
Define the author of commits

git pull
# edit files
git commit -am “Implemented X”
git push
git log
git show
https://help.github.com/articles/generating-ssh-keys/
Learn the basics: http://try.github.com/

How to write a good commit message
●
Your attitude towards commit messages should be the same as for code:
it is written once,but read thousands of times.
●
Don't explain how was done,that is visible in the diff anyway.Explain
what the intention was and why it was made.
●
Use imperative form “Fix typo”(instead of “Fixed typo”)
●
Keep subject line short and sweet,under 72 chars.Body can be verbose.
●
Use proper English.Capital letters.Reference issue identifiers is
possible.
●
Looking for a good example? How about one by Linus himself?
https://github.com/torvalds/linux/commit/fc90888

Use git commit -a --amend to you screwed up
the commit and want to overwrite the latest
with an improved commit.
Completely delete the last commit:
git reset --hard HEAD^
Delete all untracked and modified files:
git clean -fdx && git reset --hard

Basically just labels that point to certain commit IDs.
Each commit ID point to its parent,thus forms a chain.

All developers branch from
master and then merge back.
New releases branch
from master.
Support releases branch
from release branch.
Image source:
http://tleyden.github.io/blog/
2014/04/09/a-successful-git-br
anching-model-with-enterprise-
support/

Git layout strategy 1/2
●
Start working on the master branch only.Don't create other
branches until you really need them.
●
Every new developer has their own branch (local clone).
●
Never break master. Push only stuff what works.Other
developers must be able to branch from master at any time
and start working on something new,instead of having to deal
with fixing a broken state that somebody else left in master.

Git layout strategy 2/2
●
If you have a need to push your work that is half-way done,that is a
good signal that you should create a new branch.
●
Typically tree kind of branches:
– feature branches
– bugfix branches
– personal branches
●
Project layout: split code up in many separate files.
– Lower likelihood of conflicting changes when branches merge.

Distributed version control?
Example scenarios at
https://git-scm.com/about/distributed

Compare changes and create diffs
git show 166a2f284875
# standard show in patch format
git diff v1.2.3..HEAD translations/ > new-translations.diff
# diff of all changes in directory translation/ since tag v.1.2.3
git diff branch1 branch2 # compare two branches
git diff branch1..branch2 # same as above
git diff branch1...branch2 # tree dots: changes on branch2 since it diverged

GUI tool: gitk
●
graphical tool to view git history (and also uncommitted changes)
●
shows all commits,tags,branch names etc in a nice way
●
with gitk you don’t need to checkout the branch/file to view it
●
includes search feature for both commit messages and commit contents
●
run “gitk example/file.h”to see the git log that affects a single file
●
“git gui blame”can be used to view graphically via the context menu that opens when
clicking on a commit with the secondary mouse button
●
view diff between any two diffs: click on first commit normally,and then click with
secondary button on the second commit and select from context menu to view the diff
●
run “gitk mariadb-10.1.4..mariadb-10.1.5”to view diff between two commits
●
you can also view diff between different branches like this
– gitk 10.1..HEAD vs gitk HEAD..10.1 vs gitk 10.1...HEAD

Other GUI tools
●
git citool –graphical tool to do selective commits easily
– you can click to select the files you want,individual hunks inside
files,and even individual lines inside hunks
– you can also write commits inside the tool’s window
●
git mergetool –tool for easy merging,
– automatically launches the pre-configured 3-way merge tool for
all conflicts (e.g.meld)

Keep branch name visible in the bash prompt:
https://github.com/ottok/tooling/blob/master/bashrc/bashrc.git

Folder /.git contains everything,
your / is just the working copy.

Folder /.git contains everything,
your / is just the working copy.
When you commit a 2 MB file /example.png,
your / will grow to 4 MB...

When you add a file,
it goes to the staging area.
The file does not go into the
actual history tree until the stage
is committed.

Git tracks content,not files!
Git history is immutable as each commit ID is the SHA-1 of
the commit data and metadata (including the commit ID of
parents).Changing any commit in the history will change the
SHA-1 commit IDs of every following commit in the chain.
If you need to change something in the history,you have to
rebase and make a new history.

Git commit IDs and rebase
Original git log --oneline
1bf7024 MDEV-8991: bind-address appears twice in default my.cnf
b2205c5 MDEV-9011: Redo log encryption does not work
cf9e6b2 Fix test failures seen on buildbot.
923827e MDEV-7949: Item_field::used_tables() takes 0.29% in OLTP RO
239e0c5 MDEV-8551 compilation fails with 10.1.6
After git rebase -i HEAD^^^
34350b9 MDEV-8991: bind-address appears twice in default my.cnf
f5f2dd9 MDEV-9011: Redo log encryption does not work
531e1ac Fixed all bugs
923827e MDEV-7949: Item_field::used_tables() takes 0.29% in OLTP RO
239e0c5 MDEV-8551 compilation fails with 10.1.6

Example of how fast-forward works 1/2
●
Branch“feature-branch-example”forked from master branch
“10.1”and has 3 commits

Example of how fast-forward works 2/2
●
Normal merge defaults to fast-forward in this case
●
●
●
Result of no fast-forward (git merge --no-ff)

Want to avoid “ugly”merge commits?
●
git config pull.ff=only
●
git config alias.ff=merge --ff-only
●
Run git rebase master to rebase you work on the master branch
before pushing or making pull request
– In MariaDB before submitting a pull request: git rebase 10.1
– You changes will be based on current 10.1 head and easy to merge
●
Run git merge on when importing changes from remote head only if
you really want to merge

Cherry-pick as alternative to merge
git cherry-pick 166a2f28487530ead0cf813ce0252baa
The commit with given ID will be applied as a new commit on
top of your current branch head (only commit ID updates).

Git bisect –find the commit that broke you app
git bisect bad # mark the checked out commit as bad
git bisect good mariadb-10.1.7 # mark the ref (=commit) good
git bisect run my-test.sh
Git automatically checks out every commit between “bad”and “good”and runs
the test script.
Test script is supposed to return 0 for good commits and non-0 for bad commits.
Exceptions are exit codes 255 and 125 that have special meaning to git bisect.
When the run is completed git will tell you the exact commit between “good”and
“bad”where the my-test.sh started to fail (exit code not 0).

Git commit hook: stop bad code entering repo
/.git/hooks$ cat pre-commit
#!/bin/bash
# Really fast check if syntax is at all parseable
for FILE in $(git diff --cached --name-only); do
if [[ "$FILE" =~ .php$ ]]; then
php -l "$FILE" 1> /dev/null
if [[ $? -ne 0 ]]; then
echo -e "e[1;33mAborting commit: PHP code contains syntax errorse[0m" >&2
exit 1
fi
fi
done

Want to put a simple shared repository on any SSH
capable server? Create a bare .git with no working files:
git init --bare
Want to have notifications when somebody commits?
Put a shell script at .git/hooks/post-receive

Continuous integration
●
Host your own Jenkins?
●
Travis-CI

Will Github (or Gitlab) profile pages
replace developers CV's?
Something to think about

Contact Seravo if you need experts in
Linux,Git,Docker,WordPress or other
open source software
Open seravo.fi
See our blog for in-depth tips

Git essentials

More Related Content

What's hot

Viewers also liked

Similar to Git essentials

More from Otto Kekäläinen

Recently uploaded

Git essentials