Versionskontroll-Commit für Manager-Lesevorgänge

Unser Manager überwacht die Git- Commits für alle unsere Projekte. In der Regel ist dies kein Problem, und ich finde es toll, dass die Versionskontrolle ein Protokoll aller Vorgänge bereitstellt, insbesondere für spätere Audits und Analysen (falls etwas schief geht).

Der Manager hat jedoch in einigen Kommentaren gefragt, woran gerade gearbeitet wird, wenn er ein Commit mit "Style Fixes" oder eine Commit-Meldung sieht, die nicht auf eine Ticketnummer in unserem Task-Management-System verweist.

Gibt es eine soziale oder technische Lösung dafür?

Weitere Informationen: Dies ist ein Wartungsprojekt, daher gibt es eine Reihe von Aufgaben, die "erst A, dann B, dann C und dann D und dann endlich X implementieren" mussten.

Weitere Informationen: Die bestimmte Festschreibungsnachricht, die beim Manager ein Flag ausgelöst hat, stand kurz davor, "einen besseren Weg zu X, Y und Z" einzuschließen, was eher einer Umgestaltungsnachricht als einer einfachen stilistischen Korrektur entspricht.

version-control management

— Peter Mortensen
quelle

Mögliches Duplikat von Wird der Verweis auf einen Fehler / ein Problem in der Festschreibungsmeldung als bewährtes Verfahren angesehen?

— gnat

Ich stimme Ihrem Manager zu. Es ist verdammt ärgerlich, sich ein zwei Jahre altes Commit-Protokoll anzusehen, um herauszufinden, wann sich etwas geändert hat, und Commits wie "Style Fixes" zu sehen. Wenn Ihr Manager nicht zulässt, dass Sie dem Aufgabenverwaltungssystem Refactoring-Aufgaben hinzufügen, ist dies ein ganz anderes Problem.

— Gort the Robot

Echtes Refactoring ist bei der Erfassung noch wichtiger als stilistische Änderungen. Zumindest sollte in der Commit-Nachricht angegeben sein, was überarbeitet wird, aber ich würde es wirklich gerne nachverfolgen, damit jeder weiß, was überarbeitet wird, QA weiß, was er genauer testen muss usw.

— Gort the Robot

^^^ was @StevenBurnap gesagt hat - das ist eine sehr gute Übung. Nur in der Lage zu sein, die Ticket-ID zu referenzieren, anstatt die Commit-Nachricht mit ausführlichen Erklärungen darüber zu belasten, welche Art von Stilverbesserungen / Umgestaltungen vorhanden sind und warum diese gewünscht werden, macht es den Wert aus. Und es gibt mehr zu , dass Aufwand Tracking, Kommunikation mit dem Management / QA etc etc. Und verstehen Sie mich nicht begonnen, wie es ist praktisch , wenn Bug - Tracker integriert mit VCS / Code - Review - Tool

— gnat

Es kommt ganz auf die Situation an. Reagiert der Manager auf ein Mitglied des Teams, das 50% seiner Zeit für das Refactoring verwendet, oder auf ein einzelnes Commit ohne Ticketbezug?

— Winkbrace

Antworten:

Gibt es eine soziale oder technische Lösung dafür?

Ich nehme an, aber das ist kein Problem .

Ihr Manager sollte wissen, was Sie tun. Sie sollten sicherstellen, dass Sie keine Arbeit erledigen, die keinen Wert bietet, oder warum Nicht-Ticket-Arbeit priorisiert wurde. Darin liegt kein Schaden. In einer idealen Welt bietet dies Vorteile, da Ihr Manager die Erwartungen an das Geschäft festlegen kann, damit Sie all diese Arbeiten ohne Druck oder Unterbrechung ausführen können.

Dies wird nur dann zu einem Problem, wenn Ihr Manager der Ansicht ist, dass nur Ticketarbeiten durchgeführt werden sollten, und verhindert, dass technische Aufräumarbeiten zu Tickets werden. Es gibt immer technische Schulden, die beseitigt werden müssen. Immer Dinge zu optimieren, weil Sie sollten, obwohl sie keinen klaren, unmittelbaren Geschäftsnutzen bieten.

— Telastyn
quelle

Wenn die stilistische Korrektur Teil des Tickets ist, an dem Sie arbeiten, und mit ihm verwandt ist, ist es nicht falsch, sie zur besseren Identifizierung separat mit derselben Ticketnummer einzuchecken, an der Sie gearbeitet haben.

Wenn Sie nur Änderungen entdecken, die vorgenommen werden müssen, und diese nicht mit dem Ticket zusammenhängen, an dem Sie gerade arbeiten, dann würde ich vorschlagen, Tickets für technische Schulden zu erstellen und sie für eine spätere Aufbereitung in Ihren Rückstand zu legen.

Während Ihrer Planung können Sie dann die mit technischen Schulden zusammenhängenden Tickets durchgehen und sie an die tatsächlichen Wartungstickets anhängen, die Sie auf diese Weise bearbeiten möchten, um die Relatierbarkeit zu verbessern.

Auf diese Weise können Sie diese Fehlerbehebungen "aus dem Nichts" beseitigen und alles unter der Kategorie der spezifischen Probleme / Tickets, an denen Sie arbeiten, zusammenfassen.

— AvetisG
quelle

Okay, aber wenn es eine Kleinigkeit ist, dann ist das völlig dumm.

— Leichtigkeit Rennen mit Monica

Tech Schulden 99,99% der Zeit ist keine triviale Veränderung. Aus diesem Grund sage ich, mache ein Ticket, anstatt in etwas anderes einzutauchen, das einen großen Kontextwechsel darstellt. Wenn es etwas Triviales ist und nichts mit dem zu tun hat, woran Sie gerade arbeiten, können Sie es dennoch unter dem Namen des Tickets, an dem Sie gerade arbeiten, mit einem separaten Kommentar einchecken. Oder denken Sie besser noch an eine Notation wie QFIX, um sie später leichter identifizieren zu können, damit Sie keine zufälligen trivialen Änderungen ohne Organisation haben.

— AvetisG

Was ist, wenn der Manager auch JIRA nach neuen Tickets ansieht und diese dann in Frage stellt? Er fragt nicht, wann Tickets von einem zukünftigen Sprint in den aktuellen verschoben werden, aber sobald jemand ein neues Ticket im Zusammenhang mit technischen Schulden erstellt, wird es in Frage gestellt.

— Rudolf Olah

Die QFIX-Notation ist etwas, mit dem Sie sich vor der Implementierung als Team unterhalten müssen. Es dreht sich alles um Kommunikation. Man springt nicht einfach ein und schreibt seine eigenen Regeln. Sprechen Sie also zuerst als Team darüber, und wenn sie nicht damit einverstanden sind, fahren Sie mit der anderen Lösung fort, die darin besteht, sie zusammen mit Ihrem Hauptticket, an dem Sie gerade arbeiten, mit einem separaten Kommentar einzuchecken. Beachten Sie jedoch erneut, dass die Änderung nur dann geringfügig ist, wenn sie keine logischen Änderungen oder umfangreiche Umgestaltungen enthält. Unschädliche, harmlose, unbedeutende Veränderungen.

— AvetisG

@omouse Es kann durchaus sein, dass Ihr Manager Mikromanagement betreibt oder nicht ordnungsgemäß mit technischen Schulden umgeht. Der Manager ist jedoch letztendlich für das gesamte Projekt und für den Code selbst verantwortlich und sollte sich daher im Idealfall auf einer bestimmten Ebene jeder einzelnen Arbeit bewusst sein, die ausgeführt wird, und warum.

— Gort the Robot

Das nervt mich auch (kein Wortspiel beabsichtigt :).

Die hilfreichsten Check-Ins enthalten Kommentare, die eindeutig sind und nicht nur die Änderungen betreffen, sondern auch die Gründe. Manchmal schreibe ich Absatzkommentare.

Gelegentlich gerate ich in Situationen, in denen eine Benutzeroberflächenanforderung nach Beginn der Entwicklung hin und her springt und ich den Code im Wesentlichen auch abprallen muss (ja, die reale Welt ist manchmal mies). In diesen Fällen halte ich es für noch wichtiger, dass meine Kommentare Klarheit darüber bieten, warum der Absprung und vor allem, warum der Code dort endet, wo er hingeht. Wenn das Management dann nach einem Gespräch mit den Kunden zurückkommt und wissen möchte, warum, kann ich es ihnen zeigen, ohne dass ich mich an die gesamte Erfahrung erinnern muss.

— Worrystone
quelle