Git Introduction

Intro

Ask as many questions as possible, if the entire talk is a tangent then I'm happy. If I monologue for 2 hrs, you might as well watch youtube.
Interrupt if something is unclear, save sidetrack questions for IST lunch (if in KA)
Origin of CM, origin of Git.
- DoD, airplanes
- Linus, initial release in 2005 then handed over to Junio Hamani
Easy to learn vs Easy to use
- I come from a time before git
- Commands with more friendly names might have been created since I learned Git
- Likeness to file system rather than other VCS
- Git is mean to replace tarballs and patches, think of commits in that way
- Think of commits in terms of changes, not in terms of files

different from for example subversion, not just for putting a file under version control.
writes to the repository, stages changes
Explain staging, cache, index

is different from for example subversion, doesn't need or affect any remote files
Commit adds a label to some staged changes
Do a few commits (create script that says hello DPIV, then add docstrings), then break down what happens:
- add stages the content. view with status
- commit creates the commit with a message, author etc. view with show and log
Commit message:
- Imperative form
- Header max 50 characters, Body max 72. Separated by empty line. Capitalize header, but don't end with punctuation
- Header explains what, body explains why, how
what is in a commit?
- author
- time
- diff
- message
- PREVIOUS COMMIT ID
existing commits NEVER change, only new ones are created, even with --amend or rebase. Prove later by checking out a "changed" commit.

Adds a reference to a commit
Add a branch (refactor), create another commit (add dundermain), show that one branch moved, explain active branch. view active branch with status

Switches which branch commit will move, moves HEAD, switches the files on disk to match the state in the commit
Check out the refactor branch, show that the dundermain is not there. Create a new commit (extract a greet function)

Rebase to the recue to clean up!
reset the merge of refactor into master
checkout refactor and rebase on top of master
resolve the conflict and show –continue
refactor is now "based on" master instead of the docstring commit, history is much nicer!
remember: rebase and merge are opposites. merge merges into itself, rebase rebases on top of the given branch!

clone into a bare repo called remote
clone the remote repo into a repo called clone
show the tracking branches
- same as all other references, just points to a commit. but moves when git syncs with remote
- explain difference between origin master and origin/master
show the remote and explain

Create a new commit in clone (change departemnt name) and commit
Push the change, show that tracking branches update in that repo, but not in the other.
Do a fetch in the other repo and show that commit appears, and tracking branches are updated
Rebase or fast forward the local branch

Keeping track of commit IDs hurts the brain, except when it doesn't.

branchnames, tags, commit IDs, all references can be used as base
caret and tilde means parent commit e.g. HEAD^ master~
multiples can be used e.g. origin/master^^ v1.0.0~~
numbers can be used, but mean different things. master~~ is the same as master~2, but master^^ is not the same as master^2
when dealing with complicated trees with lots of merge commits, use commit IDs :)
:/ can be used to match commit message
@ is show for HEAD