Hallo,
kennt jemand ein gutes interaktives Git-Tutorial auf Deutsch oder
Englisch (egal). Ich kenne schon die wichtigsten Befehle, also ich weiß,
wie ich etwas comitte (schreibt man das im Deutschen so?), einen neuen
Branch erstelle, usw. Aber wie "benutze" ich Git richtig? Wann erstelle
ich einen neuen Branch, wann macht es sinn zu committen, usw .. zu
diesen Fragen suche ich ein Tutorial, am besten mit einem kleinen
Beispiel-Projekt, in dem möglichst alles Wichtige vorhanden ist. Habe
dazu schon was gefunden, aber ohne Code/Projekt, so ist das ganze sehr
trocken ..
Danke schon mal^^
Jonathan K. schrieb:> Aber wie "benutze" ich Git richtig?
Da gibt es kein richtig und kein falsch. git erlaubt fast beliebige
Workflows, alles kann, nichts muß.
Mit den Stichwörtern "git" und "workflow" sollte Google was passendes
ausspucken. Ob da allerdings interaktive Tutorials dabei sind, keine
Ahnung. Vielleicht gibt's zumindest was auf YouTube.
Oliver
Oliver S. schrieb:> Da gibt es kein richtig und kein falsch. git erlaubt fast beliebige> Workflows, alles kann, nichts muß.
Ja schon, aber man soll ja z.B. nur dann committen, wenn der Code
funktioniert, macht man es dann doch (also wenn der Code gerade nicht
funktioniert), ist es auch nicht falsch?
Oliver S. schrieb:> Mit den Stichwörtern "git" und "workflow" sollte Google was passendes> ausspucken
Okey ich guck mal :)
Jonathan K. schrieb:> Ja schon, aber man soll ja z.B. nur dann committen, wenn der Code> funktioniert, macht man es dann doch (also wenn der Code gerade nicht> funktioniert), ist es auch nicht falsch?
"falsch" ist es nicht, siehe
https://en.wikipedia.org/wiki/Continuous_integration
der workflow bei git/svn etc. hängt SEHR stark von den anforderungen ab
- da gibt es kein "genau so" ..
wenn du etwas alleine entwickelts kannst du commits auch als art
snapshot ansehen..
Wie mein Vorschreiber schon meinte, hängt vom Umfeld ab.
Alleine kann mans auch als eine Art Snapshot/Archivierungstool
verwenden.
In einem größeren Umfeld kann dann ein Build aber auch mal ein paar
Stunden dauern und wenn Dein kaputter Code zum Buildbreaker wird, dann
regelt sich das nach ein paar mal auch von selbst....
Jonathan K. schrieb:> aber man soll ja z.B. nur dann committen, wenn der Code> funktioniert,
Das ist zwar in den allermeisten Fällen sinnvoll, aber git selbst ist
auch das völlig egal.
Komplexe Workflows sind vor allem dann gefragt, wenn größere Teams an
einem Projekt arbeiten. Als Hobbyprogrammierer mach dir da keinen
unnötigen Stress.
Oliver
Jonathan K. schrieb:> Ja schon, aber man soll ja z.B. nur dann committen, wenn der Code> funktioniert, macht man es dann doch (also wenn der Code gerade nicht> funktioniert), ist es auch nicht falsch?
Du kannst ja zum Beipiel auch erstmal nur lokal commiten um deine
Veränderungen bei der Entwicklung nachvollziehen zu können. Und wenn du
dann fertig bist und alles läuft, kannst du mit einem rebase die
einzelnen commits zu einem großen zusammenfassen und dann erst ins
Projektrepo pushen.
Wobei du bereits gepushte commits nicht mit rebase zusammenfassen
solltest, da andere auf den Einzelcommits aufgesetzt haben könnten...
Zu deinem Haupt anliegen kann man ffesthalten, dass git so viele
Möglichkeiten bietet es zu benutzen, dass es in verschiedenen
Projektteams auch zwei völlig unterschiedliche Arbeitsweisen geben kann.
Schau dir bei Github mal paar große Projekte an und versuche deren
Workflow nachzuvollziehen.
https://git-scm.com/book/de/v1 ziemlich gutes Tutorial und im Kapitel 5
findest zu Hinweise zum Workflow in Projekten. Grundsätzlich solltest
du, wenn du dich an Projekten beteiligst, an deren Workflow halten und
nicht versuchen, dort deinen Stempel aufzudrücken. Die Leute hab sich
meist etwas dabei gedacht so zu arbeiten bzw. sind es halt so gewöhnt.
Du glaubst nicht wieviel Streitpotential in dem Thema Workflow im
Projekt steckt. :D
Im AngularJS-Tutorial wird ein wenig mit git gearbeitet. Ich fands ganz
nett, aber der Fokus liegt natürlich klar auf AngularJS und nur minimal
auf git.
https://docs.angularjs.org/tutorial
Okey danke für die weiteren Antworten :)
Aber noch ne Frage:
irgendeintyp schrieb:> Wobei du bereits gepushte commits nicht mit rebase zusammenfassen> solltest
Das gilt also nur, wenn ich nicht der einzigste Nutzer der Repository
bin, oder?
Jonathan K. schrieb:> Das gilt also nur, wenn ich nicht der einzigste Nutzer der Repository> bin, oder?
Ja kann man so sagen, aber sobald du es irgendwo veröffentlichst
solltest du dich daran halten.
irgendeintyp schrieb:> Jonathan K. schrieb:>> Das gilt also nur, wenn ich nicht der einzigste Nutzer der Repository>> bin, oder?>> Ja kann man so sagen, aber sobald du es irgendwo veröffentlichst> solltest du dich daran halten.
Okey danke alles klar.
ffff schrieb:> das ganze hätte 3 Schritte benötigt:>> 1) git bei google eingeben> 2) auf den ersten Treffer klicken> 3) auf "Try Git" klicken>> https://try.github.io/levels/1/challenges/1
Les meine Frage nochmal ...
Die Seite kannte ich übrigens auch schon vorher
ffff schrieb:> Ähm: reine Glaubensfrage was du wie richtig machst. Frag 5 Leute und du> kriegst 10 Antworten
Das ist ungefähr dieser Thread in zwei Sätzen zusammengefasst :)
Jonathan K. schrieb:> Ja schon, aber man soll ja z.B. nur dann committen, wenn der Code> funktioniert, macht man es dann doch (also wenn der Code gerade nicht> funktioniert), ist es auch nicht falsch?>
Nein, du sollst so früh wie möglich commiten, damit die Änderungen klein
sind.
Ich mache es teilweise so, das ich nach ca. 20 Commits erst testen, weil
ich die HW z.B. daheim habe.
Wenn ein Fehler bei einem deiner Commits auftritt kannst du ihn per 'git
bisect' finden.
Dieses Model wird z.B. Linux Kernel verwendet
