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.
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!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.git commit -v
git commit --fixup
as a more powerful git commit --amend
aka the crap,
this is missing from the commit over theregit rebase -i
for tidyness:
git log --oneline --graph --all
for an overview of the current branchesgit log --oneline --stat
for a rough understanding of what happened in some
commitsgit bisect
git reflog
[alias]
lf = "log --pretty=oneline --stat"
lg = "log --pretty=oneline --graph"
[commit]
cleanup = scissors
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.
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:
Tidyness is achieved by periodic interactive rebasing (git rebase -i
).
Hooks are helpful.
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.
Aber: vim ist definitiv lernenswert!
Gibt's wohl, hab ich aber noch nicht benutzt:
Ich nehme grundlegenden Konflikt war:
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
(re
based ba
chelorarbeit), dann reba
und reba2
, und
zuletzt reba2
und yolo
.
Vielleicht könnte hieraus ein nettes Pattern werden. Aber ...
Schnackt mich bei Gedanken dazu gern an.
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"^
or smth similar in good: tummychow/git-absorb.