Version Control System richtig nutzen

Hi

Ich fange ein neues Projekt an welches später komplex wird. Dazu möchte ich auch ein Version Control System benutzen (Git, Mercurial,...). Meine Frage lautet: Wie nutze ich so ein VCS richtig und effizient?

Mir wurde Mal beigebracht nach jeder Funktionsdeklaration, Parameteränderung, Includeeintragung bzw. nach jeder kleinsten Änderung ein Commit zu machen. Nur kommt das mir echt mühsam vor und irgendwie bremst das mein Denkfluss.

Ich meine, bei einem Projektstart kommen da zu Beginn ein dutzend Commits

+#include <iostream>

// Commit

+class A
+{
+};

// Commit

class A
{
+public:
+    void doA();
};

// Commit

+void A::doA()
+{
+    std::cout << "A" << std::endl;
+}

// Commit

Wie macht es ihr?

Bedanke mich im voraus. Danke

volkard

OneQuestion schrieb:

Mir wurde Mal beigebracht nach jeder Funktionsdeklaration, Parameteränderung, Includeeintragung bzw. nach jeder kleinsten Änderung ein Commit zu machen. Nur kommt das mir echt mühsam vor und irgendwie bremst das mein Denkfluss.

Offensichtlich bis Du einem falschen Profeten erlegen. Du weiß natürlich besser, wie oft Du committen solltest.

nman

Oft bis sehr oft committen ist gut, aber…

OneQuestion schrieb:

Mir wurde Mal beigebracht nach jeder Funktionsdeklaration, Parameteränderung, Includeeintragung bzw. nach jeder kleinsten Änderung ein Commit zu machen.

…ist natürlich Blödsinn.

Mit "oft committen" ist oft "semantisches Commiten" (Achtung, soeben aus dem Ärmel geschüttelter Begriff, der da draußen ziemlich sicher nicht verwendet wird!) gemeint. Also so, dass Du pro Bugfix einen Commit hast, oder pro Feature oder pro [x-beliebige kleine Einheit, die Dir sinnvoll erscheint].

Wichtig ist nur, dass Du nicht Ewigkeiten vor Dich hinarbeitest und dann am Ende des Tages einen Hundertezeilen langen "aktuelle Änderungen"-Commit raushaust.

BasicMan01

Am Anfang eines Projektes kommt es durchaus vor, dass mal größere Batzen Code im Versionierungssystem landen. Wichtig (zumindest für mich) ist es, das es ein funktionierender compilierbarer Stand ist.
Bei fortgeschrittenen Projekten sollten voneinander unabhängige Änderungen auch separat commitet werden.
Wenn man mit so einem Tool arbeitet, sollte es einem während des Entwicklungsprozesses auch bewusst sein, dass es das gibt. Bedeutet also, nicht 20 Bugs beheben und dann alles auf einmal committen mit dem Kommentar "Fehlerbehebung",
sondern Bug beheben, committen und super coolen Kommentar dazu abgeben.

Edit: zu seinem Beispiel...
das ist natürlich Blödsinn.
Schreibe deine Klasse fertig, bis das Grundkonzept steht und committe es, wenn se funktioniert.

BasicMan01 schrieb:

Am Anfang eines Projektes kommt es durchaus vor, dass mal größere Batzen Code im Versionierungssystem landen. Wichtig (zumindest für mich) ist es, das es ein funktionierender compilierbarer Stand ist.

Es sollte ein weitgehend fehlerfreier Stand sein.

Also frei von offensichtlichen Fehlern.
Das man alle Fehler nicht finden kann ist klar, aber die offensichtlichen müssen raus.
D.h. das Programm darf nicht einfach abstürzen, sondern muß laufen.

Daher sollte man das vor dem Commit schon testen.

EXDW

Das kann ich so nicht unterschreiben.

Spätestens am Ende des Tages sollte man schon Submitten, wenn der PC nicht wieder hoch kommt ist nix weg.
Die zwischenstände, ob fehlerfrei oder nicht, oder ob sie überhaupt bauen spielt dabei gar keine Rolle, dafür gibt es den Dev branch, evtl noch ein temporären private Branch den man nach dem Mergen wieder löschen kann.

Nur nach Main kommen nur stable Versionen, inkl labeln.

Man sollte trotzdem etwas nachdenken beim Submitten, nicht einfach alles alle 30 min rein drücken.

CSL schrieb:

Das kann ich so nicht unterschreiben.

Spätestens am Ende des Tages sollte man schon Submitten, wenn der PC nicht wieder hoch kommt ist nix weg.
Die zwischenstände, ob fehlerfrei oder nicht, oder ob sie überhaupt bauen spielt dabei gar keine Rolle, dafür gibt es den Dev branch, evtl noch ein temporären private Branch den man nach dem Mergen wieder löschen kann.

Wenn du in einem Team arbeitest, dann ist es eine selbstverständlichkeit, daß du denen einen sauberen Branch hinterläßt und wenn du am Wochenende heim gehst, dann willst du am Montag mit einem funktionierenden Code anfangen und nicht noch den Fehler vom Freitag suchen.
Denn da hast du schon längst wieder vergessen, wo der Fehler war.

EXDW

Ich arbeite in einem Team, genau deshalb Sprach ich ja von nem Private branch.

Den krempel auch nicht funktionstüchtig nach dev zu schieben ist hauptsächlich bei 1man projekten.
Im Team erstellt man sich ein privat Branch, dort macht man was man als sinnvoll erachtet, und sobald der bereich "final" ist, merged man das nach Dev.

Und immer bevor ein GM gebaut wird, wird es nach Main gemerged.

Private Branch = Immer der aktuelle stand, ob baubar oder nicht spielt keine rolle
Dev Branch = Zusammenfassungen woran alle gerade arbeiten
Main Branch = Stable versions von den die GMs gebaut werden.

In meiner Firma ist es sogar noch so das neben den private branches noch feature branches existieren, wovon aber nicht alle gebraucht machen.

Es gibt auch Kollegen die Submitten erst nach Dev wenn ihre Arbeit fertig ist, so kommt es vor das sie über ne Woche nicht submitten, und das finde ich persönlich unverantwortlich, das unterwandert die ganzen möglichkeiten eines SCM, das Mergen wird dadurch deutlich schwerer, und von der ausfallsicherheit red ich noch gar nicht.

Im TFS kanns man wenigstens nach Shelf schieben, wenn der Kollege krank wird oder vom Bus überfahren ist seine ganze Arbeit nicht public.

BasicMan01

hört sich gut an. Darf ich fragen, welches Versionierungstool ihr verwendet @CSL.
Ich tendiere derzeit dazu, von SVN auf Mercurial umzuwechseln über kurz oder lang

EXDW

Auf arbeit verwenden wir TFS, ist sehr performant (dicke Hardware dahinter), sehr praktisch ist es dadurch das wir SCM, TaskTracking, Test-, Buildsystem sowie Entwicklung in VS 2010 haben. All-in-one sozusagen.

Privat verwende ich Git (Git ist wie ich hörte ähnlich wie Mercural und versteht auch SVN).