Hi, mir sind in letzter zeit mehrfach Dinge im GIT repo aufgefallen, die meines Erachtens besser gemacht werden können.
Ich arbeite auch noch nicht soo lange mit git, aber einige dinge werden bei euch entgegen der bestreben von GIT gehandhabt (zumindest entgegen dem wie ich es verstehe).
Als erstes richte ich mich mal gegen die Mitglieder der Organization IlchCMS (Ich verallgemeinere jetzt der Einfachheit halber mal das alle zZ nur an Ilch 1.2 Arbeiten):
1. Commitet nie direkt in das Team-Repo!
Nicht einer von euch hat ein eigenes Repo für das Arbeiten. Wenn ihr etwas bearbeiten wollt, fort euch das repo in euren Privaten GitHub Account bearbeitet das dort und stellt dann nen Pull-Request.
Vorteile:
* Es gibt keine privaten Entwicklerbranche im Hauptrepo, diese erzeugen u.a. unnötig Traffic beim abgleichen. Ich brauch zB keinen extra Branch dafür, das iwan mal was für das issue #10 gemacht wurde. wenn ichs unbedingt wissen will schaue ich in die Commit-historry. Und wenns noch nicht nach Master gemergt wurde, sollte sich eh nur der entwikler darum kümmern. wenns den nciht mehr gibt nützt dieser halbfertige Branch idr eh keinem was.
* Wenn ihr euch angewöhnt nach jeder in sich geschlossenen Sache nen Commit zu machen können diese als ein Pull Request eingereicht, als Resultat begutachtet und Kommentiert werden.
2. Wie oben erwähnt, gewöhnt euch an reichlich zu zwischen Committen.
Dies hat den Vorteil, dass ihr wenn ihr mal feststeckt einfacher zu nem früheren Entwicklungszeitpunkt zurück springen könnt. außerdem habt ihr mehr Möglichkeiten euer Handeln zu erläutern (Stichwort Commit-Message).
Wenn ihr es dann später als Pull Request einreicht kann man sich auch nur die Diffs des Ergebnisses anzeigen. Unabhängig davon wie viele "zwischencommits" gemacht wurden. Weiterhin ist es auch möglich im Nachhinein Commits zusammen zu fassen, falls man das möchte.
3. Der selbe Tipp wie damals in der Schule: Niemals einfach vom Nachbarn abschreiben, egal was für ein Genie er ist: Einen Fehler macht er immer.
* Damit meine ich Wenn ihr eure Arbeiten dann als Pull request eingereicht habt, nie selber annehmen. Wartet bis ein anderer Entwickler des Teams on kommt. Dieser soll eure Arbeit nochmal mindestens überfliegen und dann Mergen. Egal wie gut man im Programmieren ist, man übersieht schnell mal nen Fehler. Und wenn man sich an diese einfache Regel hält schauen immer MINDESTENS 2 Paar Augen über jeden Commit.
4. Da es mir gerade am Beispiel von MVN050 auffällt: Ein issue ist auch EINE "Frage {f}; Problem {n}; Punkt {m}; Streitpunkt {m}; Diskussionspunkt {m}; Sachverhalt {m}"[BEOLINGUS].
Keine Sammlung selbiger. Wir sind jetzt bei 62, es schadet keinen wenn ihr für jedes Problem eine eigenes issues aufmacht. Oder wenn ihr nur allgemein diskutieren wollt nutzt bitte das Forum (Wie schon erwähnt wäre es in dem Zusammenhang schön, wenn die Ilch 1.2 Beta Sektion für alle einsehbar wäre).
So, da es jetzt kurz nach eins ist, habe ich jetzt keine Lust auf ne Rechtschreibkontrolle. Kommentare dazu könnt ihr euch also schenken. Zu inhaltlichen Diskussionen bin ich gerne Bereit genauso wie für weitere Hinnweise für die "richtige" Nutzung von GIT.
finke
Zuletzt modifiziert von finke am 14.09.2012 - 01:16:53
Beitrag zur Merkliste hinzufügen
Hier kann eine Notiz zum Merk-Eintrag hinzugefügt werden (optional)
ilch Forum » Allgemein » Plauder Ecke » Ein Paar tips für das arbeiten mit GIT
| Geschlossen | ||
-
-
Also gerade im ersten Punkt muss ich dir widersprechen, es macht durchaus Sinn branches im Hauptrepo zu haben (diese sind Issue bezogen, also nicht unbedingt Entwicklerbezogen), da auch mehrere Leute somit in diesem branch arbeiten können, das ist ja u.a. der Sinn und Zweck einer Versionsverwaltung, dass da jetzt noch alte branches rumgeistern, von Entwicklern die nicht mehr aktiv sind, ist natürlich nicht optimal, aber ich bin noch nicht dazu gekommen, sie mir anzuschauen.
Ich werde auch immer mal unbenutzt Branches löschen, damit da nicht so viel Unordnung herrscht.
Wenn man alleine im eigenen Kämmerchen werkelt, kann man natürlich auch im eigenen Repo arbeiten oder eben auch erst Pushen, wenn man soweit fertig ist.Und auch immer mal ein Blick auf die FAQ werfen. | Mairus Ilchseite -
Fr. 14.09.2012
09:03 Uhr
#3
KoernerWS gelöschter UserZumal kein Traffic durch zusätzliche Branches entsteht, wenn man diese nicht abgleichen lässt, wenn man das nicht möchte. Wie es derzeit läuft, ist schon der richtige Weg.
Dass man nicht mehrere Punkte in einem Issue anspricht, haben wir in dem genannten Issue auch erwähnt. -
Nochmal zu dem ersten Punkt, weil sich bei den Widersprüchen sehr auf Trafic und den Branches bezogen wird. War vielleicht doch bisschen sehr spät für sonen Post.
Diese beide Punkte waren mehr so als Zusatz gedacht. Das direkte erledigen von Issues durch ein Commit in den Master Branch ist nicht so einfach nachvollziehbar. Wenn das aber in nem Privaten Repo gemacht wird, und anschließend via Pull request eingebaut wird, ist es später sehr einfach nachvollziehbar was wer wann und weshalb gemacht hat. Als Beispiel Vergleich issue #63 und #56.
Bei #63 Wurde etwas nachgebessert. Allerdings finde ich nirgens in der Commit/Pull History, wo dieser issue bearbeitet wurde. Also schau ich erst mal in die geschlossenen Pull requestts, nichts, jetzt suche ich mir den Issue Eintrag raus, schaue was stand da drin und dann rate ich, welche Commits damit etwas zu tun haben. Ev schaue ich noch in die Network Grafik ob ich dort noch Hinweise finde. Ich muss mir meine Infos von Verschiedenen Quellen zusammen suchen.
Wenn ich mir jetzt im Vergleich issue #56 anschaue finde ich in der Commit-Historry Das Mergen, schaue in die Pull Requests, sehe da einen und finde auf einen schlag die wichtigen Commits und Kommentare in übersichtlich und in chronologischer Reihenfolge. Wenn ich genaueres wissen will kann ich mir den Commit anschauen.
Ist natürlich meine Sicht der Dinge. Wenn ihr das anders seht werde ich das natürlich respektieren.
finke -
Sa. 15.09.2012
11:12 Uhr
#5
- Registriert seit
- 09.09.2012
- Beiträge
- 149
- Beitragswertungen
aber dann gib doch mal bitte eine etwas detailiertere Vorgehensweise vor, denn ich weiß gerade nicht was ich wirklich hätte anders machen sollen bei einem einzigen Commit zu Issue#63 -
Ja Issue 63 hat eine gewisse Sonderstellung, das war nur ein Commit der eine Datei betraf und als Basis nicht den master Branch hatte, weswegen ich ihn nicht komplett einmergen wollte, deswegen hab ich ein cherry pick auf diesen Commit gemacht, womit nur die install.php aus diesem einem Commit des branches Isse63 gemacht wurde, ich habe BigEasy auch schon gesagt, dass er neue Branches immer vom master Branch aus anlegen soll, dann sollte sowas auch nicht mehr wirklich passieren.
Du bist ein echt genauer Beobachter
Und auch immer mal ein Blick auf die FAQ werfen. | Mairus Ilchseite -
angefangen habe ich noch nicht, aber diese Tipps werde ich merken.WERBUNG entfernt!
Gruß Lord|Schirmer
| Geschlossen | ||
 |
Zurück zu Plauder Ecke | |
Optionen: Bei einer Antwort zu diesem Thema eine eMail erhalten