Git training for sysadmins

(or, how to tolerate and even benefit from git)

Panu Kalliokoski, 16.1.2015

( man git ) Well, not stupid, actually quite smart (in an artificial intelligence-ish way), but…

→ no way would this come so far if it wasn't for Linus' personal support!

That said… - git's evolving really fast

git can do some stuff that doesn't really exist in other version control tools (like rebase over content moves, and git-rerere)
git's got good cloud support (i.e. Github)
git makes most easy stuff hard and hard stuff easy!

In centralised vc, history is only in one repository used by everyone
In distributed vc, every working directory has its own history.
- Histories are copied (and changes merged) between repositories
- Some repos might be accessible for many people
- push & pull models

but, in practice, usually one repository works as a sync repo in DVCS too… so what's the difference?

Pretty simple! Either:

mkdir project; cd project; git init
- this initialises whichever directory as a git repository
- you can work, commit etc., but no push/pull because there's no origin repository
Set up a public repository in Github or source02.csc.fi
1. clone some existing project or create a new project
2. make a local git repository by git clone url

git pull --ff-only — bring your local working directory up-to-date
edit files etc. in an ordinary way
- git add file.txt — tell git about a new file to be tracked
make a commit out of a logical set of changes
- git commit -am description — commit all new work
- git add -p; git commit — commit only some part
repeat from (2) if you don't want to publish your changes yet
git pull --rebase — merge your work with what others have been doing
git push — publish your work to your remote repository
go home.

The git pull --rebase is where the magic is
It takes others' new work and reapplies your changes to this new context
Sometimes (usually, if you don't touch the same lines) it goes smoothly…
When it doesn't… there's a conflict and you have to specify the result of merging

ensure you don't have anything else going on (more on this later)
git pull — get the remote changes (you can explicitly tell to git pull origin master)
git diff — should show you the conflicts
edit them away by hand (gedit some-file-that-conflicted)
git commit -am — commit your resolution of the changes
git push — test if the push is now clean
If it isn't, retry pulling…

git status
git rebase --abort — ensure you aren't in the middle of a rebase
git diff --cached — ensure you don't have uncommitted changes:
- … if they aren't your changes: git reset HEAD
- … if they are your changes: git commit -m explanation of the changes
git checkout master (or whatever branch you were working on) — ensure that you are where you want to be:

git pitää kirjaa myös ainakin:

at least three ways:

no, parameterization is almost always better