Gute Software braucht gute Dokumentation – ohne unnötigen Aufwand. Eine erste Anlaufstelle ist häufig die `Readme.md`-Datei in git-Repositorys. Aber: für wen schreibe ich die eigentlich? Was sollte, was muss da rein? Wie formatiere ich die Readme-Datei mit Markdown?
Natürlich lernt man git am besten, in dem man es täglich nutzt. Wer aber die git-Integration in der IDE nutzt hat vielleicht keinen Bezug mehr zu den eigentlichen Konsolen-Befehlen des Versionscontrollsystems. Hier daher ein paar Fragen zu git, wie ich sie auch gerne in Klassenarbeiten stelle…
Zugegeben: die meisten Leute meinen, wenn sie von git reden eher Plattformen wie GitHub, GitLab oder Bitbucket. Wir sollten diese zentralen Repositories als schleunigst einbinden…
Ein großer Vorteil von git ist, dass wir zeitgleich an unterschiedlichen Komponenten eines Projekts arbeiten können, und diese Entwicklungen zu definierten Zeitpunkten wieder zusammenführen können. Diese Entwicklung in Branches minimiert Seiteneffekte, fordert aber etwas Grips…
Bevor wir uns in die weite Welt von Github, Gitlab, Bitbucket usw. aufmachen wollen wir erst einmal verstehen, was lokal passiert und ein paar Begriffe klären: Was ist ein Commit? Was ist ein Repository? Was ist der Workspace? Was ist die Stage? In welchen Schritten versioniere ich? Wie gestalte ich meine Commit-Nachrichten?
