Neuer Entwickler kann mit dem Zusammenführen von Filialen nicht Schritt halten

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

Mein Problem ist das Folgende: Wir verwenden git- Ich schneide einen Zweig aus unserem developZweig aus und arbeite dann an der kleinen Aufgabe, die mir zugewiesen wurde. Es ist sehr langsam, weil ich unerfahren bin. Bis ich bereit bin, meinen Zweig wieder in developden anderen zusammenzuführen, haben sich so viele Änderungen ergeben, dass die Lösung der Konflikte überwältigend ist (es scheint tatsächlich einfacher, meine Arbeit zu streichen und mit der Aufgabe neu zu beginnen, was natürlich keine nachhaltige Lösung ist ).

Wie überwinde ich das? Gibt es eine Taktik, die ich anders anwenden kann als "besser codieren"? Ich habe vor, dies nächste Woche mit meinem Vorgesetzten zu besprechen.

Sie erhalten Zusammenführungskonflikte, wenn die Änderungen, die Sie in Ihrer Filiale vorgenommen haben, in der Nähe der Änderungen liegen, die Ihre Kollegen in der developFiliale in der Zwischenzeit vorgenommen haben, dh wenn Sie und Ihre Kollegen dieselben Codezeilen oder benachbarte Zeilen in derselben Datei geändert haben.

Um die Wahrscheinlichkeit von Zusammenführungskonflikten zu verringern, können Sie versuchen, früher zusammenzuführen, sodass Ihre Kollegen in der Zwischenzeit weniger Zeilen geändert haben, oder Sie können versuchen, weniger Zeilen selbst 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 einige Ihrer Experimente möglicherweise Zeilen 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 diffund um git diff --stagedzu sehen, welche Zeilen Sie geändert haben.
• git add -p um nur einige Ihrer Änderungen in eine Datei einzufügen.
• git commit --amendund git rebase -ium Commits zu optimieren, die Sie bereits in Ihrem lokalen Feature-Zweig vorgenommen haben, bevor Sie sie in andere Git-Repositorys verschieben.

(Ändern so wenige Zeilen wie möglich auch leichter machen Sie es Ihre Arbeit zu überprüfen oder Werkzeuge zu verwenden , die auf die Unterschiede zwischen Arbeit verpflichtet wie git cherry-pick, git rebase, git bisect, und git blame.)

Aber selbst wenn Sie die Wahrscheinlichkeit von Zusammenführungskonflikten verringern, stoßen Sie manchmal immer noch auf Zusammenführungskonflikte. Fürchte dich also nicht vor ihnen, sondern lerne, wie du die Konflikte lösen kannst.

Ich nehme an, du benutzt git. Wenn ja, nutzen Sie git rebase -i(das -ibedeutet interaktiv). Machen Sie es sich zur täglichen Aufgabe (noch häufiger, falls erforderlich), Ihren Zweig gegen den Entwicklungszweig aufzuspielen. Dadurch werden die Änderungen (zumindest) täglich schrittweise vorgenommen, um den Zweig Ihrer Funktionen auf dem neuesten Stand zu halten. Wenn es während Ihrer täglichen Arbeit 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 es dauert noch eine ganze Weile, bis ich mich mit einem neuen Projekt vertraut gemacht habe. In Ihrem Fall klingt es so, als würden mehrere Personen gleichzeitig an einem 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 brauchen , um in Schwung zu kommen. Wenn ich für zwei oder drei Wochen zwischen Projekten umschalte und dann zurückschalte, kann es einige Stunden (oder sogar ein oder zwei Tage) dauern, bis ich wieder vollständig in ein Projekt eingetreten 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 benutze merge. Das ist auch eine Option. Das Obige wäre also: "Nutzen Sie git rebase -i(das -ibedeutet interaktiv) oder git merge". Überlegen Sie, welchen Sie verwenden möchten, mit dem Rest Ihres Teams. Sie können so oder so starke Vorlieben haben (oder auch nicht). Es ist klar , einige Leute haben starke Präferenzen haben.

Dies könnte ein Zeichen für ein schlechtes Software-Engineering seitens des Unternehmens sein. Zu viele gegenseitige Abhängigkeiten, unterschiedliche Probleme mit überlappenden Features, der Versuch, Probleme in der falschen Reihenfolge anzugehen usw. können die von Ihnen beschriebene Situation verursachen. Ich schlage vor, dass developSie sich während der Entwicklung regelmäßig in Ihre Branche einfügen

Die akzeptierten Antworten sind meiner Meinung nach eher ein technisches "wie man Git besser einsetzt". Ich denke, dies ist eher ein Teamproblem als ein Konstruktions- 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, den persönlichen Raum beim Codieren zu entwickeln und es zu vermeiden, in Bereichen zu arbeiten, die bereits beschäftigt sind.

In meinem Team tendieren wir zu einem hohen Maß an Eigenverantwortung.
Normalerweise besitze ich zwei oder drei Dateien gleichzeitig und bearbeite sie höchstens ein oder zwei Tage lang in einer Zweigstelle.
Wenn jemand diese Dateien berührt, ist dies in der Regel nur dann unbedingt erforderlich, wenn dies für die eigenen Aufgaben erforderlich ist. In der Regel arbeiten wir überhaupt nicht an demselben Aufgabenblock zusammen.

Wenn Sie feststellen, dass Sie überhaupt eine Menge 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 sind.

Alles in allem sind Sie als neuer Entwickler wahrscheinlich nicht in der Lage, irgendeine Art von Umstrukturierung durchzusetzen, anzufordern oder sogar vorzuschlagen.
Was ich erwarten würde, ist, dass Ihre Aufgaben als "Learn-the-Ropes" -Stoff zugewiesen wurden, der auf Ihrem Kenntnisniveau einigermaßen zugänglich sein sollte, um Sie in das Team zu lockern. Sie wurden wahrscheinlich aus den Aufgaben eines Mitarbeiters ausgeschlossen, der immer noch in demselben Bereich arbeitet, daher Ihre Zusammenführungskonflikte.
Die Lösung für dieses Problem ist dann, es zu beseitigen, die Probleme zu lösen, die Zusammenführungskonflikte so gut wie möglich zu bewältigen und sich nicht zu viele Sorgen zu machen, solange Sie Ihr Bestes geben, obliegt es Ihrem Manager, sich Sorgen zu machen dein Fortschritt.
Sie werden schneller und sicherer, wenn Sie gehen,

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:

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

Wenn Sie viel Zeit in Anspruch nehmen, ist dies möglicherweise darauf zurückzuführen, dass Sie die meiste Zeit damit verbringen, herauszufinden, um welche Änderungen es sich handelt, und dann einige Zeit damit, die Änderungen zu implementieren. Führen Sie in diesem Fall die Zusammenführung 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 dieselbe Datei, sondern derselbe Code. Also brauche ich eine neue Funktion functionA und du brauchst eine neue Funktion functionB, und wir beide fügen sie am Ende derselben Datei hinzu, wir haben einen Konflikt. Wenn wir es an verschiedenen Stellen hinzufügen, entsteht kein Konflikt. Wenn wir es beide an einer Stelle in der Datei einfügen, an der es logischerweise gehört, besteht die Möglichkeit, dass wir keinen Konflikt haben.

Wenn Sie Konflikte haben, besorgen Sie sich ein gutes Diff-Tool, damit Sie den Entwicklungszweig vor dem Zusammenführen, Ihren Code vor dem Zusammenführen, Ihren Originalcode 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 Sie erneut von der Entwicklung und wenden Sie alle Änderungen an, die Sie manuell vorgenommen haben, anstatt sie erneut einzugeben.

Mit der Zeit bin ich bereit , zu verschmelzen in meinen Zweig zurück zu entwickeln (Hervorhebung von mir)

Der Umgang mit Konflikten in git mergeist oft einfacher als in git rebase. In Git Merge können Sie die gesamte Liste der Dateien sehen, die auf einmal geändert wurden. Unabhängig davon, wie viele Commits von anderen Mitarbeitern durchgeführt wurden, müssen Sie diese einmal zusammenführen . Bei einem Rebase-Workflow kann es vorkommen, dass Sie immer wieder dieselben Konflikte haben und diese manuell überprüfen müssen. Sie können am Ende das 13. Commit reparieren und das Gefühl haben , kein Licht aus dem Tunnel zu sehen .

Nach meiner Erfahrung habe ich, als ich versuchte, wiederholte Rebase-Konflikte naiv zu lösen, die Änderungen von jemandem oder eine Anwendung verloren, die nicht einmal kompiliert wurde. Oft haben ich und meine Kollegen viel Arbeit geleistet, wurden jedoch von der Komplexität der wiederholten Konflikte so überwältigt, dass wir unsere vorherige Arbeit abbrechen und verlieren mussten, nachdem eine Handvoll Rebase-Commits ausgeführt worden waren.

Ich werde Ihnen ein paar Techniken vorschlagen, die jedoch nur dazu beitragen können, dass das Zusammenführen einfacher wird als das Automatisieren der Aufgabe.

• Ressourcen- / Sprachdateien . Wenn Sie additive Änderungen an einer Ressource - Datei, stellen Sie sicher , dass Sie immer sie bis zum Ende der Datei bewegen , so dass Sie leicht erinnern können Ihre Änderungen gegen andere "Änderungen. Möglicherweise können Sie Ihre Änderungen kopieren und unten einfügen oder einfach die Konfliktmarkierungen entfernen
• Machen. Nicht. ABSOLUT. Erneut formatieren . Weder Sie noch Ihre Mitentwickler dürfen während der täglichen Arbeit eine "massive Code-Neuformatierung" durchführen. Die Code-Neuformatierung fügt eine übermäßige Anzahl von Fehlalarmen beim Konfliktmanagement hinzu. Eine Code-Neuformatierung kann durchgeführt werden
  • Inkrementell, z. B. von jedem Entwickler bei jedem Commit, sobald er ein automatisiertes Tool verwendet (z. B. hat Eclipse die Option, beim Speichern neu zu formatieren, Vanilla Visual Studio hat keine). Absolut jeder Entwickler muss dieselben Code-Formatierungsstandards verwenden, die in einer Formatdatei codiert sind, die von Ihrer IDE verwendet 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 dasselbe verwenden.
  • Kurz vor der Entlassung durch einen Teamleiter. Wenn eine "Code-Neuformatierung" festgeschrieben wird, wenn Benutzer nicht an Zweigen arbeiten, d. H. Bevor sie verzweigen, wird dies einfacher
• Überprüfen Sie die Arbeitsteilung zwischen Mitarbeitern. Dies ist der Teil, an dem die meisten Ingenieure beteiligt sind. Wie andere Antworten zeigen, ist es Design-Geruch, 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 überbeanspruchen Menschen ihre Filialen. Ich habe persönlich gesehen, wie ein Entwickler 10 bis 20 Commits mit der Bezeichnung "fix" hinzufügte, von denen jedes eine oder zwei Zeilen festlegte. Unsere Politik ist, dass Commits mit JIRA-Tickets gekennzeichnet sind, um Ihnen eine Idee zu geben.

@JacobRobbins schlägt vor, git rebaseeine tägliche Aufgabe zu erledigen. Ich möchte seine Annäherung vorantreiben.

Verwenden Sie zunächst einmal rebase, um die Anzahl der Commits auf eine Handvoll zu reduzieren. Und stützen Sie sich nur auf den ursprünglichen Entwicklungszweig, von dem aus Sie verzweigt sind. Wenn ich Handvoll sage, könnte ich 3 oder 4 bedeuten (z. B. alle Frontends, alle Backends, alle Datenbank-Patches) oder jede vom Menschen vernünftige Zahl. Nachdem Sie sie konsolidiert haben, verwenden fetchund bearbeiten 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 Ihr Leben wird weniger schmerzhaft.

Wenn Sie weitere Fragen zu bestimmten Aufgaben haben, können Sie nach Stackoverflow suchen und diese stellen.

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

Schließlich verpflichtet Sie die Pfadfinder-Regel nicht, das Chaos anderer Leute zu beseitigen. Nur deins.

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

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 zu viele Konflikte vorliegen, ist Ihre Aufgabe möglicherweise geringfügig, wiederholt sich jedoch. Versuche ein Muster zu finden. Dies würde bei der Lösung von Konflikten mit den Git UI-Client-Tools helfen. Ich benutze TortoiseGit. Es hilft beim Zusammenführen.

Und um 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 eine Verzweigungserstellung bietet. Dies sollte auf jedem Einchecken aufbauen, das Sie in Ihrem Feature-Zweig vornehmen, jedoch nach dem Zusammenführen des Entwicklungszweigs.

Sie sollten regelmäßig (täglich) den Befehl 'git fetch' (nicht git pull) aus Ihrem Entwicklungszweig ausführen. Auf diese Weise 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 leitenden Entwickler 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 verbreitet. Warten Sie nicht bis nächste Woche - finden Sie den Prozess jetzt heraus und fragen Sie, ob Sie einige triviale Arbeiten (wie das Formatieren von Code oder das Hinzufügen von Kommentaren) ausführen können, um den Prozess zu testen.

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

Trotzdem sehe ich viele Antworten, die empfehlen, regelmäßig zu entwickeln. Ich wäre von solchen Ratschlägen viel weniger begeistert. Ihr Ziel an dieser Stelle ist es, den Konfliktlösungsprozess so einfach und sicher wie möglich zu gestalten. Eine Sache, die enorm bei diesem Prozess helfen wird, ist, dass sofort so viele Regressionstests 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 unweigerlich Konflikte lösen, während Sie mit der Implementierung Ihrer Funktion zur Hälfte fertig sind. Und das bedeutet, dass es viel schwieriger sein wird, herauszufinden, was der Code tun soll, da Sie damit noch nicht fertig sind. Stellen Sie vor dem Zusammenführen sicher, dass Ihr Zweig eine zusammenhängende Änderungseinheit ist. Noch besser,

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

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

Das klingt nach einem idealen Szenario für die Paarprogrammierung !

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

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

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

Sie müssten den besten Ansatz für den bestimmten Code in Ihrem Projekt herausfinden, da die Paarprogrammierung für einige Projekte nicht immer sinnvoll ist - obwohl das Lernen immer sinnvoll ist, selbst wenn Sie nur sitzen und jemandem zusehen, der erfahrener ist als Sie (Solange sie ein guter Entwickler sind, bedeutet Erfahrung nicht unbedingt, dass sie gute Praktiken anwenden).

Wenn Sie mit einem schnelleren und erfahreneren Entwickler zusammensitzen, können Sie Folgendes tun:

• Vermindert wahrscheinlich Zusammenführungskonflikte, da die Zusammenarbeit mit einer erfahreneren Person die Ausführungszeit im Gegensatz zu Ihrer alleinigen Arbeit verlängert
• Da sie Ihnen beibringen werden, ist es wahrscheinlich, dass sie langsamer sind als wenn sie alleine arbeiten würden. Es kann also immer noch zu Zusammenführungskonflikten kommen, und Sie können mit erfahrenen Personen zusammenarbeiten
• Erläutern Sie mögliche Tricks und Möglichkeiten, schneller zu sein (obwohl Langsamkeit manchmal nur ein Mangel an Erfahrung und nicht an bewährten Methoden ist).
• Kann sofort Fragen stellen, wenn etwas keinen Sinn ergibt oder nicht 100% klar ist
• 1: 1 zu arbeiten ist nützlich, um zu lernen, da die Person, die Sie um Hilfe bitten, bereits den genauen Code und das Szenario versteht, während sie daran arbeitet Sie verlieren also ihre Zeit / Aufmerksamkeit, wenn Sie wirklich dringend benötigte Ratschläge erhalten
• Lernen Sie den Denkprozess eines erfahrenen und erfahrenen Menschen kennen und lernen Sie mit guter Kommunikation ganz sicher neue Dinge

Gibt es eine Taktik, die ich anders anwenden kann als "besser codieren"? Ich habe vor, 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 die Chance gibt, die Profis der Paarprogrammierung zu präsentieren (wenn sie das brauchen, wissen die meisten Leute Bescheid und es ist allgemein bekannt, warum es hilft).

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

1) Im Idealfall würden Sie Ihre Branche jeden Tag in die Entwicklung einbinden. Versuchen Sie, mindestens einmal am Tag über Arbeitscode zu verfügen, der alle Tests besteht, damit Sie in die Entwicklung einbinden können.

2) Wenn Sie an einem beliebigen Punkt Ihres normalen Arbeitstages keinen Arbeitscode haben, haben Sie wahrscheinlich zu große Codestücke, an denen Sie arbeiten können. Sie müssen Ihre Aufgabe in kleinere Aufgaben aufteilen, die (im Idealfall unabhängig voneinander) schneller erledigt werden können, damit Sie sie zusammenführen können.

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

4) Ihr Team ist möglicherweise zu groß. Wenn Sie es einfacher finden, ein ganzes Feature wegzuwerfen und von vorne zu beginnen, ist es wahrscheinlich, dass zu viele Leute Code in dasselbe Repository schreiben.

5) Möglicherweise verfügen Sie nicht über einheitliche Code-Formatierungsstandards. Wenn Sie nicht alle konsistent dieselbe Code-Formatierung verwenden, treten für denselben Code viele verschiedene Konflikte auf. Abhängig davon, wie Ihr Git eingerichtet ist, kann es sogar zu Leerzeichen-Konflikten kommen (Zeilenenden, Einrückungen, Tabulatoren oder Leerzeichen).

6) Möglicherweise leiten die Mitarbeiter ihre Änderungen direkt an die Entwicklungsabteilung weiter.

Hier ist, was Sie tun können: 1) Wenn Sie nicht jeden Tag in die Entwicklung einbinden können, führen Sie jeden Tag (oder öfter) die Entwicklung in Ihrer Zweigstelle 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 Code-Organisation (kleinere Dateien, kleinere Funktionen).

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

Meistens ist es das, was ich tue, 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 .....

Es ist also nichts Falsches daran, einen neuen Zweig vom Master aus zu erstellen, Ihre Arbeit darin zu wiederholen und über Ihren "privaten Zweig" 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 Master-Zweig eingefügt werden. Beispielsweise können die 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 von ihnen Gebrauch machen, sodass das Risiko geringer ist, dass andere Benutzer dieselbe Benutzeroberflächendatei bearbeiten.

Wenn Sie den Entwicklungszweig nicht zu oft in Ihrem Zweig zusammenführen möchten, können Sie einen Workflow erhalten, der eher svn ähnelt, indem Sie verwenden git pull --rebase. Dadurch werden die neuen Commits abgerufen und Ihre Commits werden auf diese zurückgesetzt. Das heißt, wenn Sie Ihre Filiale in Develop zusammenführen, handelt es sich um eine schnelle Zusammenführung (als hätten Sie alle Ihre früheren Commits nacheinander zur gleichen Zeit hinzugefügt), ohne dass Zusammenführungskonflikte aufgetreten sind, da Sie sie alle während des Vorgangs aufgelöst haben git pull --rebase.

Aber je mehr Festschreibungen Sie vornehmen, bevor Sie entweder Ihre Niederlassung in "Entwickeln" oder "Entwickeln" in Ihre Niederlassung integrieren, desto komplizierter wird die nächste Neugründung, und das Gefühl von Feature-Verzweigungen wird ein wenig untergraben, da Ihre Niederlassung nur existiert, solange sie nicht zusammengeschlossen ist .

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

1. Aufgaben unabhängig voneinander aufteilen:

   Planen und unterteilen Sie vor Beginn Ihrer Arbeit die gesamten Aufgaben so, dass die zugewiesenen Aufgaben für jedes Teammitglied so unabhängig und modular wie möglich sind (um mögliche Konflikte während der Entwicklung zu vermeiden). Sie können sich an Ihren Scrum Leader wenden, um einige unabhängige Aufgaben für Sie als Neuling zu vergeben.

2. Zusammenführen granularer häufiger Commits:

   Warten Sie nicht, bis die gesamte Aufgabe abgeschlossen ist, bevor Sie den letzten Schritt machen. Natürlich können auch größere Aufgaben in mehrere Unteraufgaben aufgeteilt werden. Besser ist es daher, kleinere Commits für kleinere Unteraufgaben gleichzeitig häufig zusammenzuführen, um eine umfangreiche Konfliktlösung zu vermeiden.

3. Bauen Sie Ihre Filiale häufig um:

   Machen Sie eine Übung für häufiges Zurücksetzen zu Ihrer lokalen Niederlassung mit einer entfernten Niederlassung. Sie können den folgenden Befehl verwenden, um Ihre lokale Niederlassung häufig durch eine entfernte zu ersetzen.

   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. Arbeite eng mit deinen Teamkollegen zusammen:

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

5. Seien Sie gewohnt mit Git-Optionen:

   Nutze die Kraft der Git-Zusammenführungswerkzeuge. Es gibt viele bequeme Möglichkeiten, Konflikte beim Zusammenführen zu lösen. Das Zusammenführen von Strategien kann manchmal sehr hilfreich sein. Sei es gewohnt und furchtlos mit Git-Befehlen.