it-swarm-eu.dev

Neue Entwickler können mit Zweigstellenzusammenführungen nicht Schritt halten

Ich bin der neue Entwickler - dies ist meine erste Programmierposition.

Mein Problem ist folgendes: Wir verwenden git - Ich schneide einen Zweig aus unserem develop-Zweig aus und beginne dann mit der Arbeit an der mir zugewiesenen Nebenaufgabe. Es ist sehr langsam, weil ich unerfahren bin. Bis ich bereit bin, meinen Zweig wieder in develop zusammenzuführen, haben die anderen so viele Änderungen vorgenommen, dass die Lösung der Konflikte überwältigend ist (es scheint tatsächlich einfacher zu sein, meine Arbeit zu verschrotten und von vorne mit der Aufgabe zu beginnen, welche von Kurs ist keine nachhaltige Lösung).

Wie überwinde ich das? Gibt es eine andere Taktik, die ich anwenden kann, als besser im Codieren zu sein? Ich beabsichtige, dies nächste Woche mit meinem Vorgesetzten zu besprechen.

225
daisy

Sie erhalten Zusammenführungskonflikte, wenn die Änderungen, die Sie in Ihrem Zweig vorgenommen haben, in der Nähe der Änderungen liegen, die Ihre Kollegen in der Zwischenzeit im Zweig develop vorgenommen haben, dh wenn Sie und Ihre Kollegen dieselben Codezeilen oder angrenzenden Zeilen in geändert haben die gleiche Datei.

Um die Wahrscheinlichkeit von Zusammenführungskonflikten zu verringern, können Sie versuchen, früher zusammenzuführen, damit Ihre Kollegen in der Zwischenzeit weniger Zeilen geändert haben, oder Sie können versuchen, selbst weniger Zeilen zu ändern.

Um weniger Zeilen selbst zu ändern, stellen Sie sicher, dass Sie nur Änderungen vornehmen, die sich auf Ihre Aufgabe beziehen.

Wenn Sie mit verschiedenen Methoden experimentieren müssen, um Ihr Ziel zu erreichen, haben möglicherweise einige Ihrer Experimente Linien geändert, die nicht wirklich geändert werden müssen? Machen Sie diese Änderungen vor dem Zusammenführen rückgängig.

Es gibt auch einige Git-Befehle, mit denen Sie so wenige Zeilen wie möglich ändern können:

  • git diff und git diff --staged um zu sehen, welche Zeilen Sie geändert haben.
  • git add -p, um nur einige Ihrer Änderungen in eine Datei einzufügen.
  • git commit --amend und git rebase -i to Tweak Commits, die Sie bereits in Ihrem lokalen Feature-Zweig erstellt haben, bevor Sie sie in andere Git-Repositorys verschieben.

(Das Ändern so weniger Zeilen wie möglich kann es auch einfacher machen, Ihre Arbeit zu überprüfen oder Tools zu verwenden, die die Unterschiede zwischen Commits wie git cherry-pick, git rebase, git bisect, und git blame.)

Aber selbst wenn Sie die Wahrscheinlichkeit von Zusammenführungskonflikten verringern, treten manchmal Zusammenführungskonflikte auf. Haben Sie also keine Angst vor ihnen, sondern lernen Sie, wie Sie die Konflikte lösen können.

7
Toxaris

Ich nehme an, du benutzt Git. Wenn ja, verwenden Sie git rebase -i (das -i bedeutet interaktiv). Machen Sie es sich zur täglichen Aufgabe (ggf. noch häufiger), Ihren Zweig gegen den Entwicklungszweig neu auszurichten. Dadurch werden die Änderungen (zumindest) jeden Tag schrittweise vorgenommen, um Ihren Feature-Zweig auf dem neuesten Stand zu halten. Wenn es während Ihrer täglichen Rebase zu Konflikten kommt, müssen Sie mit Ihrem Team darüber sprechen, wer an was arbeitet.

Wenn Sie es täglich ausführen, benötigen Sie den interaktiven Teil wahrscheinlich nicht. Lass es einfach sein Ding machen.

Ich bin ein ziemlich erfahrener Entwickler, und ich brauche noch einige Zeit, um mich mit einem neuen Projekt vertraut zu machen. In Ihrem Fall klingt es so, als würden mehrere Personen gleichzeitig an demselben Projekt arbeiten. Es handelt sich also entweder um ein sehr großes Projekt oder um ein neues Projekt, das sich schnell weiterentwickelt. Machen Sie sich in beiden Fällen keine Sorgen, wenn Sie mehrere Monate benötigen, um in den Fluss zu gelangen. Wenn ich 2 oder 3 Wochen lang Projekte wechsle und dann zurückwechsle, kann es einige Stunden (oder sogar ein oder zwei Tage) dauern, bis ich wieder vollständig in ein Projekt "zurück" bin, das ich zu 100% selbst geschrieben habe!

Kurz gesagt, mach dir keine Sorgen, dass du jetzt langsam bist. Der Weg, um besser zu werden, besteht darin, einfach weiter zu üben. Haben Sie keine Angst, andere Entwickler nach Aspekten der Projekte zu fragen, die Sie nicht verstehen.

BEARBEITEN:

Oder verwenden Sie merge. Das ist auch eine Option. Das Obige wäre also: "benutze git rebase -i (das -i bedeutet interaktiv) oder git merge ". Über die zu verwendende Person sprechen Sie mit dem Rest Ihres Teams. Sie können (oder auch nicht) starke Vorlieben haben. Es ist klar, dass einige Leute dies tun haben starke Vorlieben.

286
Jacob Robbins

Dies könnte ein Zeichen für schlechtes Software-Engineering seitens des Unternehmens sein. Zu viele Abhängigkeiten, unterschiedliche Probleme mit überlappenden Funktionen, der Versuch, Probleme in der falschen Reihenfolge zu beheben usw. können die von Ihnen beschriebene Situation verursachen. Ich schlage vor, develop während der Entwicklung regelmäßig in Ihrem Zweig zusammenzuführen

130

Die akzeptierten Antworten sind meiner Meinung nach eher ein technisches "Wie man Git besser nutzt". Ich denke, dies ist eher ein Teamproblem als ein Engineering- oder Werkzeugproblem.

Wenn Sie auf viele Zusammenführungskonflikte stoßen, bedeutet dies, dass Sie und eine andere Person im Team sich gegenseitig auf die Zehen treten.
Sie oder sie sollten darauf abzielen, beim Codieren persönlichen Raum zu schaffen und nicht in Bereichen zu arbeiten, die bereits beschäftigt sind.

In meinem Team tendieren wir zu einem hohen Maß an Eigenverantwortung.
Normalerweise übernehme ich zwei oder drei Dateien gleichzeitig vollständig und vollständig und arbeite höchstens ein oder zwei Tage lang in einer Filiale daran.
Wenn jemand diese Dateien berührt, ist dies normalerweise nur dann der Fall, wenn dies für seine eigenen Aufgaben unbedingt erforderlich ist. Im Allgemeinen arbeiten wir überhaupt nicht an demselben Aufgabenblock zusammen!

Wenn Sie feststellen, dass Sie überhaupt viel zusammenführen müssen, befindet sich entweder der gesamte Code Ihres Teams an einem Ort (was an sich zu vermeiden ist) oder alle Ihre Aufgaben.

Alles in allem sind Sie als neuer Entwickler wahrscheinlich nicht in der Lage, irgendeine Art von Umstrukturierung durchzusetzen, anzufordern oder sogar wirklich vorzuschlagen.
Was ich erwarten würde, ist, dass Ihre Aufgaben als "Lernsachen" zugewiesen wurden, die auf Ihrem Können angemessen zugänglich sein sollten, um Ihnen den Einstieg in das Team zu erleichtern. Sie wurden wahrscheinlich von den Aufgaben eines Kollegen ausgeschlossen, der immer noch im selben Bereich arbeitet, daher Ihre Zusammenführungskonflikte.
Die Lösung hierfür besteht darin, das Problem zu lösen, die Zusammenführungskonflikte so gut wie möglich zu lösen und sich nicht zu viele Sorgen zu machen, solange Sie Ihr Bestes geben Ihr Manager kümmert sich um Ihre Fortschritte.
Sie werden schneller und selbstbewusster, wenn Sie gehen, und Ihre Mitarbeiter geben Ihnen mehr Autonomie und stehen Ihnen dadurch weniger im Weg.

97
Rowan

Das Wichtigste beim Zusammenführen ist, dass es umso schmerzhafter wird, je länger Sie warten. Und das Problem wächst mehr als linear. Dreimal so viele Konflikte sind neunmal so viel Arbeit. Es gibt einige Strategien:

Schließen Sie sich bei jeder Änderung mit dem Entwicklungszweig zusammen, damit Sie immer in der Nähe sind und nie eine große Anzahl von Konflikten haben.

Wenn Sie viel Zeit in Anspruch nehmen, kann dies daran liegen, dass Sie die meiste Zeit damit verbringen, herauszufinden, was die Änderungen sind, und dann ein wenig Zeit damit verbringen, die Änderungen zu implementieren. Wenn dies der Fall ist, führen Sie eine Verknüpfung mit dem Entwicklungszweig durch, bevor Sie mit den eigentlichen Codeänderungen beginnen.

Sprechen Sie mit Ihren Kollegen über Strategien zur Vermeidung von Konflikten. Sie erhalten Konflikte, wenn zwei Personen denselben Code bearbeiten. Nicht nur die gleiche Datei, sondern der gleiche Code. Ich brauche also eine neue Funktion functionA und Sie brauchen eine neue Funktion functionB, und wir fügen sie beide am Ende derselben Datei hinzu. Wir haben einen Konflikt. Wenn wir es an verschiedenen Stellen hinzufügen, kein Konflikt. Wenn wir es beide an einer Stelle in der Datei hinzufügen, zu der es logischerweise gehört, haben wir wahrscheinlich keinen Konflikt.

Wenn Sie haben Konflikte, besorgen Sie sich ein gutes Diff-Tool, damit Sie den Entwicklungszweig vor dem Zusammenführen, Ihren Code vor dem Zusammenführen, Ihren ursprünglichen Code und den zusammengeführten Code vergleichen und von Hand zusammenführen können.

Schlimmster Fall: Sie werfen Ihre Arbeit nicht weg, sondern verwenden ein gutes Diff-Tool, um genau herauszufinden, welche Änderungen Sie vorgenommen haben, verzweigen erneut von der Entwicklung und wenden alle manuell vorgenommenen Änderungen an, anstatt sie erneut einzugeben.

29
gnasher729

Bis ich bereit bin, zusammenzuführen meinen Zweig wieder zu entwickeln (Hervorhebung meiner)

Umgang mit Konflikten in git merge ist oft einfacher als in git rebase. In Git Merge sehen Sie die gesamte Liste der Dateien, die gleichzeitig geändert wurden. Unabhängig davon, wie viele Commits von anderen Mitarbeitern ausgeführt wurden, müssen Sie einmal zusammenführen. Mit dem Rebase-Workflow erhalten Sie möglicherweise immer wieder dieselben Konflikte und müssen sie manuell überprüfen. Sie können am Ende das 13. Commit korrigieren und das Gefühl haben , dass Sie kein Licht aus dem Tunnel sehen können .

Als ich versuchte, wiederholte Rebase-Konflikte naiv zu lösen, verlor ich meiner Erfahrung nach die Änderungen einer Person oder eine Anwendung, die nicht einmal kompiliert wurde. Oft haben ich und meine Mitarbeiter viel Arbeit geleistet, waren jedoch von der Komplexität der Wiederholung von Konflikten so überwältigt, dass wir unsere vorherige Arbeit nach einer Handvoll Rebase-Commits abbrechen und verlieren mussten.

Ich werde Ihnen einige Techniken vorschlagen, die jedoch nur dazu beitragen können, dass die Zusammenführung einfacher wird als die Automatisierung der Aufgabe.

  • Ressourcen-/Sprachdateien. Wenn Sie additive Änderungen an einer Ressourcendatei vorgenommen haben, stellen Sie sicher, dass Sie diese immer an das Dateiende verschieben, damit Sie Ihre Änderungen gegen andere 'Änderungen. Möglicherweise können Sie Ihre Änderungen unten kopieren und einfügen oder einfach die Konfliktmarkierungen entfernen
  • Nicht. ABSOLUT. RE-Format. Weder Sie noch Ihre Kollegen dürfen während der täglichen Arbeit eine "massive Code-Neuformatierung" durchführen. Durch die Neuformatierung des Codes wird eine übermäßige Anzahl von Fehlalarmen im Konfliktmanagement hinzugefügt. Eine Neuformatierung des Codes kann durchgeführt werden
    • Inkrementell, z. von jedem Entwickler bei jedem Commit, sobald er ein automatisiertes Tool verwendet (z. B. hat Eclipse eine Option zum Neuformatieren beim Speichern, Vanilla Visual Studio hat keine). Absolut jeder Entwickler muss dieselben Code-Formatierungsstandards verwenden, die in einer Formatdatei codiert sind, die von Ihrer IDE verarbeitet wird. Um Ihnen eine Idee zu geben, wenn es 4 Leerzeichen oder 2 Tabulatoren sind, spielt es keine Rolle, aber es ist wirklich wichtig, wenn alle das gleiche verwenden.
    • Kurz vor der Veröffentlichung von einem Teamleiter. Wenn ein "Code-Neuformatierungs-Commit" auftritt, wenn Personen nicht an Zweigen arbeiten, d. H. Bevor sie verzweigen, werden die Dinge einfacher
  • Rückblick die Arbeit, die zwischen Mitarbeitern aufgeteilt wird. Dieser ist der Teil, wo die meisten Technik kommt. Wie aus anderen Antworten hervorgeht, ist es ein Designgeruch, wenn mehrere Entwickler, die unterschiedliche Aufgaben ausführen, dieselben Ressourcen berühren müssen. Möglicherweise müssen Sie mit Ihrem Teamleiter besprechen, welcher Teil von jedem gleichzeitigen Entwickler geändert werden soll.

Ich habe auch einige schlechte Gewohnheiten in Git-Workflows in meinen Teams gesehen. Oft sind die Leute zu sehr in ihren Filialen engagiert. Ich habe persönlich gesehen, wie ein Entwickler 10 bis 20 Commits mit der Bezeichnung "Fix" hinzugefügt hat, die jeweils eine oder zwei Zeilen festschreiben. Unsere Richtlinie lautet, dass Commits mit JIRA-Tickets gekennzeichnet sind, um Ihnen eine Vorstellung zu geben.

@JacobRobbins schlägt vor, git rebase eine tägliche Aufgabe. Ich möchte seinen Ansatz vorantreiben.

Verwenden Sie Rebase nur einmal, um die Anzahl der Commits auf eine Handvoll zu reduzieren. Und stützen Sie sich nur auf den original Entwicklungszweig, von dem aus Sie verzweigt haben. Wenn ich Handvoll sage, könnte ich 3 oder 4 (z. B. alle Front-End-, alle Back-End-, alle Datenbank-Patches) oder eine menschlich vernünftige Zahl bedeuten. Nachdem Sie sie konsolidiert haben, verwenden Sie fetch und arbeiten Sie Ihre Rebase über den Upstream-Zweig. Dies wird Sie nicht vor Konflikten bewahren, es sei denn, Ihr Team überprüft seinen eigenen Ansatz, aber es wird Ihr Leben weniger schmerzhaft machen.

Wenn Sie weitere Fragen zu den spezifischen Aufgaben haben, können Sie auf Stackoverflow suchen und fragen.

[Bearbeiten] über die No-Reformat- und Boy-Scout-Regel. Ich habe RE-Format leicht umformuliert, um hervorzuheben, dass ich die Aufgabe habe, die gesamte Quelldatei, einschließlich des von Ihnen nicht berührten Codes, von Grund auf neu zu formatieren. Im Gegensatz dazu, dass Sie immer Ihren eigenen Code formatieren, der perfekt für Pfadfinder geeignet ist, werden eine Reihe von Entwicklern, einschließlich meiner selbst, verwendet, um die gesamte Datei mit den Funktionen der IDE neu zu formatieren. Wenn die Datei von anderen berührt wird, wird dies von Git als Konflikt angesehen, auch wenn die betroffenen Zeilen in Inhalt und Semantik nicht geändert werden. Nur ein sehr leistungsfähiger sprachbewusster Editor kann darauf hinweisen, dass der Konflikt nur mit der Formatierung zusammenhängt und das am besten formatierte Fragment automatisch zusammenführt. Aber ich habe keine Beweise für ein solches Werkzeug.

Schließlich schreibt die Pfadfinderregel nicht vor, dass Sie das Chaos anderer Leute beseitigen müssen. Nur deins.

Denken Sie zunächst nicht daran, Ihre Änderungen zu verwerfen. Sie verlieren die Gelegenheit, den Zusammenführungsprozess zu lernen.

Zweitens suchen Sie eine Person, die an den Dateien gearbeitet hat, die Konflikte verursachen. Sie können die Geschichte sehen. Sprechen Sie mit der Person und lösen Sie Konflikte in diesen Dateien. Machen Sie dasselbe für andere Konflikte.

Wenn es zu viele Konflikte gibt, ist Ihre Aufgabe möglicherweise geringfügig, wiederholt sich jedoch. Versuche ein Muster zu finden. Dies würde bei der Lösung von Konflikten durch die Git UI-Client-Tools helfen. Ich benutze TortoiseGit. Es hilft beim Zusammenführen.

nd um es in Zukunft zu vermeiden

  • Es ist eine sehr gute Praxis, den Entwicklungszweig regelmäßig mit Ihrem Feature-Zweig zusammenzuführen.

  • Wenn Sie CI aktiviert haben, prüfen Sie, ob das CI-Tool einen Zweigaufbau bereitstellt. Dies sollte auf jedem Check-in aufbauen, den Sie in Ihrem Feature-Zweig vornehmen, aber nach dem Zusammenführungsentwicklungszweig.

6
PKV

Hier liegen einige Probleme zugrunde. Ihre Probleme beim Zusammenführen sind höchstwahrscheinlich nicht Ihre Schuld und sind häufiger ein Symptom für schlechte Praktiken.

1) Idealerweise würden Sie Ihren Zweig jeden Tag zur Entwicklung zusammenführen. Versuchen Sie, mindestens einmal am Tag Arbeitscode zu haben, der alle Tests besteht, damit Sie sich in die Entwicklung einfügen können.

2) Wenn Sie zu keinem Zeitpunkt Ihres normalen Arbeitstages über Arbeitscode verfügen, haben Sie wahrscheinlich zu große Codestücke, um daran zu arbeiten. Sie müssen Ihre Aufgabe in kleinere Aufgaben aufteilen, die (idealerweise unabhängig voneinander) schneller erledigt werden können, damit Sie sie zusammenführen können.

3) Ihre Projektdateien sind wahrscheinlich zu groß. Wenn es für eine Datei viele Zusammenführungskonflikte gibt, arbeiten zu viele Personen an einer Datei. Idealerweise sollte etwas, an dem eine Person arbeitet, von dem getrennt sein, woran alle anderen arbeiten.

4) Ihr Team ist möglicherweise zu groß. Wenn Sie es einfacher finden, eine ganze Funktion wegzuwerfen und von vorne zu beginnen, gibt es wahrscheinlich zu viele Leute, die Code in dasselbe Repository übertragen.

5) Möglicherweise haben Sie keine einheitlichen Code-Formatierungsstandards. Wenn Sie nicht alle konsistent dieselbe Codeformatierung verwenden, treten viele unterschiedliche Konflikte für denselben Code auf. Abhängig davon, wie Ihr Git eingerichtet ist, kann es sogar zu Leerzeichenkonflikten kommen (Zeilenenden, Einrückungen, Tabulatoren oder Leerzeichen).

6) Die Leute könnten ihre Änderungen direkt an den Entwicklungszweig weiterleiten.

Folgendes kann Sie tun: 1) Wenn Sie nicht jeden Tag in die Entwicklung einbinden können, führen Sie die Entwicklung in Ihrem Zweig jeden Tag (oder häufiger) zusammen.
2) Versuchen Sie, Ihren Code vom Code aller anderen zu trennen.
3) Sprechen Sie mit dem Rest des Teams über kleinere Funktionen, konsistente Codierungsstandards und eine bessere Codeorganisation (kleinere Dateien, kleinere Funktionen).

2
xyious

Es scheint tatsächlich einfacher zu sein, meine Arbeit zu verschrotten und von vorne zu beginnen, was natürlich keine nachhaltige Lösung ist.

Meistens ist dies das, was ich mache. Wenn ich zum ersten Mal einen Fehler behebe oder eine Änderung am System vornehme, lerne ich, wie es geht. Wenn ich das nächste Mal denselben Fehler behebe, dauert es nur 1% der Zeit, da ich das Problem jetzt verstehe.

Ich finde auch, dass ich, wenn ich ein bisschen Arbeit wiederhole, besseren Code schreibe .....

Daher ist es nichts Falsches, wenn Sie vom Master aus einen neuen Zweig erstellen, Ihre Arbeit darin wiederholen und Ihren "privaten Zweig" verwenden, um Sie daran zu erinnern, was Sie tun müssen.

Es ist auch möglich, dass Sie eine Möglichkeit gefunden haben, Ihre Änderung in logische und korrekte Teile aufzuteilen, die nach Abschluss jeweils in den Hauptzweig eingefügt werden. Beispielsweise können Unit-Tests und Änderungen am Backend-Code durchgeführt und zusammengeführt werden. Anschließend können Sie in einem separaten Vorgang die Änderungen an der Benutzeroberfläche vornehmen, die diese verwenden, sodass das Risiko geringer ist, dass jemand anderes dieselbe Benutzeroberflächendatei bearbeitet.

1
Ian

Wenn Sie den Entwicklungszweig nicht zu oft in Ihrem Zweig zusammenführen möchten, können Sie mit git pull --rebase Einen Workflow erhalten, der eher svn ähnelt. Dadurch werden die neuen Commits abgerufen und Ihre Commits darauf zurückgesetzt. Dies bedeutet, dass beim Zusammenführen Ihres Zweigs mit "Entwickeln" ein schneller Vorlauf zusammengeführt wird (als hätten Sie alle Ihre früheren Commits gleichzeitig nacheinander hinzugefügt) und keine Zusammenführungskonflikte auftreten, da Sie sie alle während des Vorgangs gelöst haben git pull --rebase.

Aber je mehr Commits Sie machen, bevor Sie entweder Ihren Zweig in "Entwickeln" oder "Entwickeln" in Ihren Zweig einbinden, desto komplizierter wird die nächste Neubasis und es wird das Gefühl von Feature-Zweigen ein wenig untergraben, da Ihr Zweig nur existiert, solange er nicht zusammengeführt ist .

1
allo

Das erste ist natürlich, zu vermeiden, dass mehrere Personen an denselben Dateien arbeiten, zumindest auf eine Weise, die zu schwierigen Konflikten führt. Das Hinzufügen von Dingen zu Aufzählungen ist kein Problem, solange ein gutes Codeformat verwendet wird. Das Ändern des Kontrollflusses auf unterschiedliche Weise und das Verschieben von Code ist weitaus schwieriger. Manchmal ist dies dennoch unvermeidlich. Sie müssen Fragen stellen, wenn Sie Konflikte lösen, die wirklich komplex sind.

Trotzdem sehe ich viele Antworten, die empfehlen, regelmäßig zusammenzuführen/neu zu entwickeln. Ich wäre viel weniger begeistert von solchen Ratschlägen. Ihr Ziel an dieser Stelle ist es, den Konfliktlösungsprozess so einfach und sicher wie möglich zu gestalten. Eine Sache, die bei diesem Prozess enorm helfen wird, ist, dass so viele Regressionstests sofort verfügbar sind, einschließlich der neuen, die Teil Ihrer neuen Funktion sind. Wenn Sie Ihren Zweig sehr regelmäßig mit der Entwicklung synchronisieren, müssen Sie ausnahmslos Konflikte lösen, während Sie zur Hälfte mit der tatsächlichen Implementierung Ihrer Funktion fertig sind. Und das bedeutet, dass es viel schwieriger sein wird, herauszufinden, was der Code tun soll, da Sie damit noch nicht fertig waren. Stellen Sie vor dem Zusammenführen sicher, dass Ihr Zweig eine kohärente Änderungseinheit ist. Noch besser ist es, es vor dem Zusammenführen in ein einziges Commit umzuwandeln.

Ich habe versucht, nicht auf die Vorzüge von Rebase over Merge einzugehen, was wahrscheinlich eine andere Frage ist. In diesem Zusammenhang spielen die Tools keine Rolle.

1
Kafein

Bis ich bereit bin, meinen Zweig wieder in die Entwicklung einzubeziehen, haben die anderen so viele Änderungen vorgenommen, dass die Lösung der Konflikte überwältigend ist

Dies klingt nach einem idealen Szenario für Paarprogrammierung !

Weitere Informationen zu den Vorteilen und grundlegenden Ansätzen:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Sie werden natürlich im Laufe der Zeit schneller arbeiten, wenn Sie alleine arbeiten, aber es kann bis dahin entmutigend sein und ist manchmal auch ein langer Weg. Während Menschen schnell lernen können, in einer stressigen Umgebung zu sein, die immer unter Druck steht, aufzuholen, werden andere, die unter ständigem Druck nicht gut lernen, behindert.

Anstatt alleine an einem Zweig zu arbeiten und zu versuchen, mit anderen Entwicklern Schritt zu halten, die offensichtlich viel schneller sind als Sie, würden Sie stattdessen direkt (mit demselben PC) mit einem anderen Entwickler arbeiten. Auf diese Weise erhalten Sie sofort Ratschläge und erhalten wahrscheinlich Tipps zur Beschleunigung usw.

Sie hätten den besten Ansatz für den jeweiligen Code in Ihrem Projekt gefunden, da die Paarprogrammierung für einige Projekte nicht immer sinnvoll ist - obwohl es für das Lernen wohl immer sinnvoll ist, selbst wenn Sie nur sitzen und jemanden beobachten, der erfahrener ist als Sie (Solange sie ein guter Entwickler sind, bedeutet Erfahrung nicht unbedingt, dass sie gute Praktiken anwenden).

Das Sitzen mit einem schnelleren, erfahreneren Entwickler kann helfen, indem:

  • Reduziert wahrscheinlich Zusammenführungskonflikte, da die Arbeit mit einer erfahreneren Person die Fertigstellungszeit verlängert, im Gegensatz zu Ihrer alleinigen Arbeit
  • Da sie Ihnen beibringen, ist es wahrscheinlich, dass sie langsamer sind als sie alleine arbeiten. Daher kann es immer noch zu Zusammenführungskonflikten kommen und sie mit jemandem durcharbeiten, der erfahren ist, und vielleicht einige Tipps zum Zeitsparen usw.
  • Helfen Sie dabei, mögliche Tricks und Wege zu erkennen, um schneller zu sein (obwohl es manchmal einfach nur ein Mangel an Erfahrung und nicht an bewährten Praktiken ist, langsam zu sein)
  • Kann sofort Fragen stellen, wenn etwas keinen Sinn ergibt oder nicht 100% klar ist
  • 1: 1 zu arbeiten ist wertvoll für das Lernen, da die Person, von der Sie um Hilfe bitten würden, den genauen Code und das Szenario bereits versteht, während sie daran arbeitet. Ohne Paarprogrammierung müssen Sie den Code und das Szenario erklären, was häufig zu Problemen führt Sie verlieren also ihre Zeit/Aufmerksamkeit, wenn Sie tatsächlich dringend benötigte Ratschläge erhalten
  • Lernen Sie den Denkprozess von jemandem kennen, der erfahrener und erfahrener ist, und mit guter Kommunikation werden Sie mit Sicherheit neue Dinge lernen

Gibt es eine andere Taktik, die ich anwenden kann, als besser im Codieren zu sein? Ich beabsichtige, dies nächste Woche mit meinem Vorgesetzten zu besprechen.

Mein Rat ist, die Paarprogrammierung mit den anderen Entwicklern zu besprechen und sich dann an Ihren Vorgesetzten zu wenden. Wenn sie anständig sind, werden sie Ihre Initiative zu schätzen wissen, die Ihnen mehr Chancen bietet, die Profis der Paarprogrammierung zu präsentieren (wenn sie das brauchen, wissen die meisten Leute davon und es ist allgemein bekannt, warum es hilft).

1
James

Wenn Sie in gemeinsamen Dateien arbeiten, müssen Sie oder Ihre Teamkollegen auf jede Weise alle Konflikte lösen, bevor das Zusammenführen abgeschlossen ist. Seien Sie also zunächst nicht verärgert . Sie machen immer noch Projektarbeit und sind stolz auf Ihre Arbeit. Um einen intelligenteren Schritt zu machen, können Sie den folgenden Vorschlägen folgen.

  1. Aufgaben unabhängig voneinander teilen:

    Bevor Sie mit Ihrer Arbeit beginnen, planen und teilen Sie ganze Aufgaben so, dass die zugewiesene Aufgabe für jedes Teammitglied so unabhängig und modular wie möglich ist (um mögliche Konflikte während der Entwicklung zu vermeiden). Sie können sich an Ihren Scrum-Leiter wenden, um Ihnen als Neuling einige unabhängige Aufgaben zuzuweisen.
  2. Zusammenführen granularer häufiger Commits:

    Warten Sie nicht, bis die vollständige Aufgabe erledigt ist, bevor Sie den letzten Schritt machen. Natürlich können größere Aufgaben in mehrere Unteraufgaben unterteilt werden. Ein besserer Ansatz ist es daher, kleinere Commits für kleinere Unteraufgaben häufig gleichzeitig zusammenzuführen, um eine umfangreiche Konfliktlösung zu vermeiden.
  3. Starten Sie Ihren Zweig regelmäßig neu:

    Üben Sie, häufig mit einer Remote-Niederlassung in Ihre lokale Niederlassung zurückzukehren. Mit dem folgenden Befehl können Sie Ihren lokalen Zweig häufig mit einem Remote-Zweig neu einrichten.

    git pull --rebase #or
    git pull --rebase Origin dev #when dev is remote branch
    

    Das ist bis jetzt der nützlichste Git-Befehl für mich in meinem Entwicklungsleben.

  4. Arbeiten Sie eng mit Teamkollegen zusammen:

    Wenn Sie wirklich parallel mit Ihrem Teamkollegen in einer gemeinsamen Aufgabe arbeiten müssen, arbeiten Sie bitte zusammen. Sie kann einige Zeit warten, um eine komplexe Konfliktlösung zu vermeiden, da Sie Neuling sind und eine Expertin sind.

  5. Mit Git-Optionen vertraut sein:

    Verwenden Sie die Power-of-Git-Zusammenführungs-Tools. Es gibt viele bequeme Möglichkeiten, Konflikte beim Zusammenführen zu lösen. Zusammenführungsstrategien kann manchmal sehr hilfreich sein. Sei es gewohnt und furchtlos mit Git-Befehlen.

1

Sie sollten regelmäßig (täglich) den Befehl 'git fetch' (nicht git pull) von Ihrem Entwicklungszweig ausführen. Dadurch werden Änderungen von anderen Personen übernommen und in Ihren Feature-Zweig übernommen, ohne dass versucht wird, die Änderungen in Ihren Zweig zu integrieren.

Dies ist etwas, worüber Sie mit dem Hauptentwickler sprechen sollten (nicht unbedingt mit Ihrem Manager), da Ihr Unternehmen möglicherweise eigene Standards oder empfohlene Methoden zur Behandlung dieses Problems hat. es ist sehr häufig. Warten Sie nicht bis nächste Woche - finden Sie den Prozess jetzt heraus und fragen Sie, ob Sie triviale Arbeit leisten können (z. B. Code-Formatierung oder Hinzufügen von Kommentaren), damit Sie den Prozess testen können.

1
PeteCon