Sie suchen nach einer technischen Lösung für ein menschliches Problem. Das geht selten.
Hier sind ein paar Ansätze, die ich entweder in der Vergangenheit verwendet habe oder im Hinterkopf habe, ohne tatsächlich die Möglichkeit zu haben, sie in der Praxis anzuwenden. Je nachdem, welche Position Sie in einem Team innehaben, treffen einige möglicherweise nicht auf Ihren Fall zu (wenn Sie ein Teamleiter mit ausgezeichnetem Ruf sind, haben Sie wahrscheinlich eine bessere Gelegenheit, Ihre Sichtweise durchzusetzen, als wenn Sie ein Student sind, der einen Abschluss hat) soeben für die Dauer Ihres Praktikums einem Team beigetreten).
Besprechen Sie das Problem mit Ihren Mitarbeitern und erläutern Sie die Konsequenzen großer Commits. Vielleicht verstehen sie einfach nicht, dass komplizierte Zusammenführungen eine direkte Folge seltener Commits sind, und kleine, häufige Commits machen Zusammenführungen (relativ) einfach.
Ich kannte viele Programmierer, die einfach davon überzeugt waren, dass Zusammenführungen immer kompliziert sind. Sie haben höchstens ein Commit pro Tag ausgeführt, es vermieden, leistungsstarke Tools wie das Diff und das automatische Zusammenführen von Visual Studio zu verwenden, und es gab eine schlechte Praxis beim manuellen Zusammenführen (es sei denn, "Take Mine" ohne weitere Diff-Inspektion ist eine gute Praxis). Für sie hatte dies nichts mit ihnen zu tun und war die Natur einer Verschmelzung.
Nennen Sie konkrete Beispiele für das, was in anderen Unternehmen geschieht (insbesondere für die, vor denen Ihre Mitarbeiter großen Respekt haben). Sie sind sich möglicherweise einfach nicht bewusst, dass es sich um ein Problem handelt, und sind davon überzeugt, dass ein Commit pro Tag maximal das ist, was jedes Team tut.
Einige Leute sind sich nicht bewusst, dass es Teams von 5 bis 10 Mitgliedern gibt, die bis zu 50 Pushs für die Produktion ausführen. Dies entspricht durchschnittlich 5 bis 10 Commits pro Tag und Person. Sie verstehen möglicherweise weder, wie es möglich ist, noch warum jemand es tun würde.
Mit gutem Beispiel vorangehen. Tu genug kleine Dinge selbst. Wenn möglich, halten Sie eine kurze Präsentation ab, in der Sie und Ihre Zusammenführungen über eine Woche lang nebeneinander dargestellt werden. Betonen Sie die eventuellen Fehler, die sie während der Zusammenführung gemacht haben, und vergleichen Sie sie mit der Anzahl der von Ihnen gemachten Fehler (die nahe bei Null liegen sollten).
Verwenden Sie gegebenenfalls die Technik „Ich habe es Ihnen gesagt“ . Wenn Sie sehen, dass Ihre Kollegen unter einer schmerzhaften Verschmelzung leiden, kommentieren Sie lautstark, dass kleine, häufige Eingaben Verschmelzungen (relativ) schmerzlos machen könnten.
Erklären Sie, dass es keine Mindestdauer für das Festschreiben gibt. Ein Commit kann sogar einer geringfügigen Änderung entsprechen, die in wenigen Sekunden vorgenommen wurde. Das Umbenennen einer Datei, das Entfernen eines veralteten Kommentars und das Korrigieren eines Tippfehlers sind Aufgaben, die sofort ausgeführt werden können.
Programmierer sollten nicht befürchten, ein kleines Commit auszuführen, sondern viele Änderungen in einem großen Commit zusammenfassen.
Arbeiten Sie gegebenenfalls mit Einzelpersonen statt mit einem Team. Wenn es eine Person gibt, die sich besonders weigert, häufige, kleine Verpflichtungen einzugehen, sprechen Sie mit dieser Person einzeln, um herauszufinden, warum sie dies ablehnt.
Möglicherweise geben sie absolut stichhaltige Gründe an, die Ihnen einen Hinweis darauf geben, was mit einem Team los ist. Einige Gründe, warum ich mich gehört habe:
„Mein Lehrer / Mentor hat mir gesagt , dass die beste Praxis ein pro Tag begehen zu tun ist.“ Es überrascht mich nicht, gegeben , was ich hatte von meinen Lehrern in der Schule zu hören .
"Meine Kollegen sagten mir, ich solle weniger Verpflichtungen eingehen." Das wurde mir auch in einigen Teams gesagt, und ich verstehe ihren Standpunkt. Wir hatten ein Protokoll, das praktisch mit meinen Verpflichtungen gefüllt war (nicht schwer zu tun, wenn vier Teamkollegen nicht einmal eine Verpflichtung pro Tag eingehen), was meine Kollegen frustrierte.
"Ich dachte, kleine Commits machen es schwierig, eine Revision zu finden." Irgendwie ein gültiger Punkt, selbst wenn das Team sich Mühe gibt, beschreibende Protokollnachrichten zu schreiben.
„Ich möchte nicht zu viel Speicherplatz auf unserem Versionskontrollserver verschwenden.“ Die Person versteht offensichtlich nicht, wie Commits gespeichert werden (und wie billig der Speicherplatz ist).
„Ich denke, ein Commit sollte einer bestimmten Aufgabe entsprechen.“ Angesichts der Tatsache, dass eine Aufgabe häufig einer Arbeit entspricht, die an einem Tag erledigt werden muss (z. B. in den Task-Boards von Visual Management), ist dies kein Zufall. Die Person sollte dann lernen, einen Unterschied zwischen einer Aufgabe in einem Rückstand (2 bis 8 Stunden Arbeit) und einer logisch isolierten Änderung zu machen, die durchgeführt werden sollte (einige Sekunden bis einige Stunden Arbeit). Dies hängt auch mit Punkt 5 zusammen.
Suchen Sie nach dem Grund, warum das Team nicht häufiger Commits durchführt. Sie werden von den Ergebnissen überrascht sein.
Kürzlich habe ich in einer anderen Antwort erwähnt, dass die Geschwindigkeit eines Commits von Bedeutung ist und sogar Hunderte von Millisekunden Entwickler dazu zwingen können, weniger häufig ein Commit durchzuführen .
Andere Gründe können sein:
Übermäßig komplizierte Regeln zum Schreiben einer Commit-Nachricht.
Die Regel, die den Entwickler zwingt, das Festschreiben mit einer Aufgabe aus einem Fehlerverfolgungssystem zu verknüpfen.
Die Angst, den Bau zu brechen.
Die Abneigung, mit dem Risiko eines sofortigen Abbruchs des Builds umzugehen: Wenn Sie am Freitagabend kurz vor der Abreise ein Commit ausführen, können Sie die Bearbeitung eines Abbruchs auf Montag verschieben.
Die Angst vor einer Fusion.
Stellen Sie fest, ob Entwickler verstehen, dass es noch weitere Vorteile gibt, die häufig zu nutzen sind . Beispielsweise ist eine Continuous Integration-Plattform ein großer Anreiz, häufige Commits durchzuführen , da damit genau bestimmt werden kann, wo die Regression eingeführt wurde .
Ich würde es vorziehen, wenn die CI-Plattform mir mitteilt, dass ich den Build in der Revision 5023 gebrochen habe, der aus einer Änderung in zwei Methoden in einer Datei besteht, die ich vor fünfzehn Minuten vorgenommen habe, und nicht in der Revision 5023, die aus Änderungen besteht, die vier Dutzend Dateien umfassen und darstellen 13 Stunden Arbeit.