MoonKid
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Wenn ich fremde Projekte patchen möchte, tue ich das idR mit PullRequests. Grob weiß ich was das ist.
Welche git Kommandos ist dafür brauche, habe ich mir aufgeschriebne.
Auch deren man-page kenne ich. Aber mir fehlt der Blick auf das große Ganze. Dieses ganze PR-Zeug ist mir immer noch zu komplex. Ich forke ein fremdes repository. origin, upstream, master, branch, etc... Ich suche eine Anleitung (kein step-by-step Tutorial), wo einem das wirklich (am besten auch visuell) mal wirklich verklickert wird, was da passiert und warum das eigentlich so kompliziert sein muss. 😉
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5347
|
MoonKid schrieb: Wenn ich fremde Projekte patchen möchte, tue ich das idR mit PullRequests. Grob weiß ich was das ist.
Welche git Kommandos ist dafür brauche, habe ich mir aufgeschriebne.
Auch deren man-page kenne ich. Aber mir fehlt der Blick auf das große Ganze. Dieses ganze PR-Zeug ist mir immer noch zu komplex. Ich forke ein fremdes repository. origin, upstream, master, branch, etc... Ich suche eine Anleitung (kein step-by-step Tutorial), wo einem das wirklich (am besten auch visuell) mal wirklich verklickert wird, was da passiert und warum das eigentlich so kompliziert sein muss. 😉
origin und upstream sind Namen fuer Repositories. master ist ein branch. Hier 2 Links aus meinen Bookmarsk. Ich bin mir aber nicht sicher, ob sie anfaengerfreundlich sind.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
sebix
Die beiden Texte scheinen konzeptuell sehr gegensätzlich zu sein, wenn ich das richtig verstehe.
#1 versucht den git-Gedanken zu erklären und man möge doch nicht gegen das eigentliche git-Konzept arbeiten. Dazu gehört z.B. auch kein --no-ff beim mergen zu verwenden.
#2 Wiederum geht damit sehr frei um. Das Konzept bei #2 verstehe ich auch ganz gut soweit. Wir setzen mal vorraus ich habe einen extra branch angelegt und diverse Änderungen darin commited.
Mal sehen ob ich es richtig verstehe: Ein git merge meinbranch reiht alle commits im extra-branch mit in den master-branch ein. In einer git gui ergibt dass dann eine einzige Linie im Revisions-Baum. Finde ich persönlich unschön. Ein git merge --no-ff meinbrach verschmilzt alle commits im extra-branch zu einem einzige und fügt diesen in master als neuen commit ein. Das sieht man dann auch im Revisionsbaum mit zwei Linien, die wieder zusammengeführt werden. (find ich schöner) Und was ist mit squash (bedeutet glaube ich Quetschen?). Also git merge --squash meinbrach fasst alle Änderungen/Commits des extra-branches zu einer gesamten Änderung (nicht commit!) zusammen und überführt zu zu master. In master ist es aber eine NICHT-commited Änderung (man sagt glaub ich gestaged?) Commited man das im master, sieht es in der git gui gleich richtig interessant aus. Die Linie vom branch hört einfach auf ohne überführende Verbindung in den master. Stattdessen sieht man auf der master-Linie den neuen (extra-branch zusamenfasssenden) commit, welcher an der Stelle ansetzt, wo der extra-brach ursprünglich gestartet ist.
Nun behauptet der erste Artikel es hat seinen Grund das --no-ff nicht als default-Verhalten konfigurierbar ist, weil man es eigentlich nicht benutzen sollte. Aha?
Und squash benutzt er aber ausgiebig. Ist nach seiner Logik auch kein Standardverhalten. Persönlich finde ich das merge ohne Extraoption am unschönsten, weil ich in der git gui (ich benutez Giggle) dann gar keine extra-Linien für die branches sehen kann. Mpf... Nun steh ich da mit vielen Möglichkeiten (es gibt sicher noch mehr) und gegensätzlichen Meinungen, die ich nicht abschließend nachvollziehen kann. Was meint ihr dazu?
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
TheDarkRose schrieb: schon https://guides.github.com/introduction/flow/ gefunden ?
Das ist ein schöner Text für Einsteiger - aber nicht das was ich suche. Es fehlen mir da die technischen Aspekte.
Warum oder warum nicht sollte ich mergen ohne Optionen, mit --no-ff oder mit squash nutzen? Warum das simple merge überhaupt jemand nutzen sollte, kann ich auch gar nicht verstehen. Dann hätte ich mir den branch auch sparen können, wenn sowieso alle commits im master eingebaut werden.
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
steht doch eh auf der seite von nvie.com damit die branch info erhalten bleiben, also das man sieht welche commits zu welchen feature gehören. somit ist es ganz einfach einen kompletten branch zu reverten. das ginge nicht so einfach, wenn die commits in den master fast forwarded werden. bei pull requests gehen sowieso keine fast forwards. squashen tut man, wenn ein branch aus vielen unsinnig kleinen commits besteht, um daraus ein paar große zu machen.
|
unbuntuS12
Anmeldungsdatum: 2. Juni 2010
Beiträge: 1816
|
MoonKid schrieb: Warum das simple merge überhaupt jemand nutzen sollte, kann ich auch gar nicht verstehen. Dann hätte ich mir den branch auch sparen können, wenn sowieso alle commits im master eingebaut werden.
Weil man sonst im Team quasi nicht parallel entwickeln kann. Wenn ich an Feature X arbeite, dann will ich in meinem Working Directory nur Commits aus dem entsprechenden Branch haben. Erst, wenn ein Feature (und das der anderen) abgeschlossen ist, macht man sich ans mergen. Dann hat man - wenn überhaupt - auch nur einmal das Theater und nicht bei jedem Commit. (zugegeben: In heißen Projektentwicklungsphasen kommt es schon man vor, dass Hals über Kopf Sachen umgeschmissen werden, die dann direkt in den develop-branch gemerged werden und die man sich dann manchmal noch aus dem develop in seinen feature-Branch reinmergen muss. Aber das sollte eigentlich die Ausnahme sein. 😬 )
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
dann schon eher den feature branch auf den develop rebasen 😉
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12829
|
MoonKid schrieb:
Warum das simple merge überhaupt jemand nutzen sollte, kann ich auch gar nicht verstehen. Dann hätte ich mir den branch auch sparen können, wenn sowieso alle commits im master eingebaut werden.
Nein. Du musst den zeitlichen Verlauf berücksichtigen: man eröffnet einen Branch, wenn man bestimmte Funktionalität unabhängig von anderen Dingen realisieren will. So lange man das auf dem Branch hat, besteht immer die Möglichkeit zu entscheiden ob und wann man den Merge macht. Siehe auch unbuntuS12s Erläuterung. Damit gewinnt man mehr Entscheidungsfreiheit darüber, was in einem Release freigegeben wird.
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Tut mir Leid, ich hatte mich wohl zu unklar ausgedrückt, oder ich hab eure Antworten falsch verstanden. Ich habe das Mergen an sich, nicht in frage gestellt. Branchen und Mergen sind mir im Prinzip logisch. Es ging mir aber um die Frage, welche der drei (mir bisher bekannten) Varianten man den nun wählt:
Warum man die erste Variante überhaupt nutzt, ist mir nicht klar. Hierbei landen ja alle mini-commits aus dem seperaten Branch im master. Das will man doch eigentlich nicht, oder? Natürlich möchte ich die mini-commits selbst irgendwie behalten - zu Doku-Zwecken. Die bleiben halt im Branch. Dafür eignen sich (nach meinem Verständnis) die zweite und dritte Variante, wobei mir nicht klar ist, wann ich welche davon (also no-ff oder squash) nutzen sollte.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12829
|
MoonKid schrieb:
Ich habe das Mergen an sich, nicht in frage gestellt. Branchen und Mergen sind mir im Prinzip logisch. Es ging mir aber um die Frage, welche der drei (mir bisher bekannten) Varianten man den nun wählt:
Warum man die erste Variante überhaupt nutzt, ist mir nicht klar. Hierbei landen ja alle mini-commits aus dem seperaten Branch im master. Das will man doch eigentlich nicht, oder?
Achso.
Natürlich möchte ich die mini-commits selbst irgendwie behalten - zu Doku-Zwecken. Die bleiben halt im Branch. Dafür eignen sich (nach meinem Verständnis) die zweite und dritte Variante, wobei mir nicht klar ist, wann ich welche davon (also no-ff oder squash) nutzen sollte.
Zum einen kann man einen Branch löschen. Das ist z.B. sinvoll, wenn man die Anzahl der Branches im Zaum halten will. Dann gehen die einzelnen Commits verloren, wenn man vorher --squash genutzt hat. Zum anderen ist es natürlich deutlich mühsamer, wenn Du erst den Branch finden musst, wenn Du erfahren willst, wer einen bestimmten Commit gemacht hat und weshalb. Bedenke, dass sich die Suche auch über mehrere Branches erstrecken kann. Wenn Du alle Commits mitnimmst, hast Du das Problem nicht: Du schaust einfach in die History auf dem main Branch (oder wo auch immer) und findest den Autor und die Commit-Meldung.
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
Ok, das sind denkbare Argumente für ein optionsloses mergen. Ob das für mich relevant wird, kann ich leider noch nicht sagen, weil ich solche Suchaktionen noch nie machen musst. Daher kommt wahrscheinlich auch meine Frage, worin den jetzt bei der praktischen Arbeit der Unterschied zwischen --no-ff und --squash besteht. Das die Revisionsbäume in einer git gui dann anders aussehen, hab ich schon gemerkt und auch verstanden.
Aber welche Auswirkung hat der kleine Strich am Ende des branches, der den branch wieder mit dem master verbindet (bei --no-ff) oder wenn er eben fehlt (bei --squash)?
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
sqash merges verwendet man eigentlich nie. fast forward heißt halt das der merge dann so aussieht als wären die commits am master gemacht wurden. ohne fast forward sieht man, dass die commits in einen seperaten branch gemacht wurden. fast forward passiert sowieso nur, wenn am akutellen branch seit erstellen des zu mergenden branch keine commits gemacht wurden.
|
MoonKid
(Themenstarter)
Anmeldungsdatum: 9. Februar 2012
Beiträge: 1379
|
TheDarkRose schrieb: sqash merges verwendet man eigentlich nie.
Diese Aussage hat sicherlich keine Evidenz. Du kennst nicht alle git-nutzenden Entwickler. Aber vielleicht kannst du mit Argumenten untermauern, warum squash nicht genutzt werden sollte. Für mich als Neuling erscheint es ganz sinnvoll, denn die mini-commits aus meinem extra branch brauch ich nicht im master.
|