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.
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
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
Oh. dann entschuldige ich mich für mein nicht-lesen. ;) Ähm: reine Glaubensfrage was du wie richtig machst. Frag 5 Leute und du kriegst 10 Antworten
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.