git

Resourcen

How I use `git`

I mostly use git from the command line. Additionally I use liquidprompt, so that my shell tells me what branch I'm on, and if I have something stashed. I also use the gitlens VS Code plugin, but for inline blame.

I generally clone with ssh to have password-free authentification.

The important commands

git diff for overview of WIP. If there is to much going on, i.e. the ouput doesn't fit in the terminal window, I should probably commit something (I mean, I can always interactive-rebase later...)
git stash to stash away my WIP and then e.g. look at another branch or try something different. Important: usually, the stash is empty!
I generally use git add -p. I never use git add -a or git add ., so that I have only the exact changes I want to have in that specific commit.
git diff --staged before I commit and git restore -p --staged, if there's something that I staged but actually don't want to commit.
Sometimes I use git commit -v
- To ensure, that the commit contains the right things
- to help me with formulating the commit message
I often use git commit --fixup as a more powerful git commit --amend aka the crap, this is missing from the commit over there
git rebase -i for tidyness:
- split up "too-big" commits into multiple atomic commits
- join multiple "too-small" commits into a single atomic commits
- Reorder commits
git log --oneline --graph --all for an overview of the current branches
git log --oneline --stat for a rough understanding of what happened in some commits
git bisect
git reflog

Config

[alias]
	lf = "log --pretty=oneline --stat"
	lg = "log --pretty=oneline --graph"

[commit]
	cleanup = scissors

hooks

hooks are nice to run low-latency checks like formatting or linting automatically when commiting. pre-commit or husky make it easier to use hooks.

Tidyness

Regarding tidyness, I think the git history is quite similar to code: It communicates intent, either to collaborators or my future self, thus I try to keep it tidy, at least as soon as I "publish" my changes, e.g. when I submit them for review.

Under tidyness I understand:

Every commit can be build, is formatted correctly and passes the test suite
Every commit is atomic
Every commit has a good commit message

Tidyness is achieved by periodic interactive rebasing (git rebase -i).

Hooks are helpful.

Other

Do X (e.g. build & test) for a range of commits

git rebase -i --exec make --exec make test ...

This is nice to e.g. run a specific test linearly over the last n commits.

In another sense this is the crutch I have to use when I cannot use git bisect since good and bad commits are intertwined.

Editor ändern

Man kann den Editor ändern.

Aber: vim ist definitiv lernenswert!

Statistiken

Gibt's wohl, hab ich aber noch nicht benutzt:

Conventional Commits

Conventional Commits: "human and machine readable meaning" für commit messages
commitlint
Semantic Release: "Fully automated version management and package publishing"

Theorycrafting

Ich nehme grundlegenden Konflikt war:

Die History soll komplett sein, denn es kommt immer wieder zu Fragen a la "warum ist das hier an dieser Stelle so?".
Die History soll kompakt sein, also "logisch" statt "chronologisch".

Könnte man diesen Konflikt lösen indem man zwei main-branches hat (einen komplett, einen kompakt) Während dem rebasen meiner Bachelorarbeit hatte mehrfach dieses Zweier-Modell: erst ba und reba (rebased bachelorarbeit), dann reba und reba2, und zuletzt reba2 und yolo.

Vielleicht könnte hieraus ein nettes Pattern werden. Aber ...

auf welchem Branch entwickeln? (Bauchgefühl: auf'm kompakten)
wie werden die zwei Branches zusammengehalten?
wie Aufwand minimieren?

Schnackt mich bei Gedanken dazu gern an.

git smash

ein kleiner Rebase-helper:

#!/usr/bin/env bash

COMMIT=$1

LSTRING=$(git show "$COMMIT" | awk '
/^\+\+\+/                                 { file=substr($2, 3) };
$1 == "@@" && match($3, /\+(.*),(.*)/, l) { print "-L" l[1] "," l[1]+l[2] ":" file };
' | paste -s -d " ")

git log "$COMMIT" $LSTRING

echo "skip how many commits? (q quits)"

read -r SKIP_UNTIL_BASE

if [ "$SKIP_UNTIL_BASE" == q ]
then
	exit
fi

# additional head necessary since -L always prints code
BASE_SHA=$(git log --format="%H" --skip="$SKIP_UNTIL_BASE" -n 1 "$COMMIT" $LSTRING | head -n 1)

git rebase -i --update-refs "$BASE_SHA"^

git