Nop schrieb:
>> 2) Nur compilierfähige Sourcen/Scripte einchecken
>
> Unbedingt. Ich krieg nen Hals, wenn ich "update" mache und dann nichtmal
> ein Build geht, weil der Kollege das nicht getestet hat.
Das sollte auf jeden Fall für den Master Branch gelten, aber nicht für
alle Entwicklungszweige. Wenn ich neue Features baue, dann werden auch
(noch) defekte Softwarestände eingecheckt. Manches lässt sich eben
gerade nicht in ein paar Stunden mit einem Commit lösen. Dann sollte die
Commit-Message aber eine Notiz wie "WIP" o.Ä. enthalten.
Claqueur schrieb:
> Checked man die Compilate bewusst nicht in
> die "Sourceverwaltung" ein, zwingt man sich, selbst Sicherzustellen das
> mit den aus der Sourceverwaltung zurückgeholten Sourcen jederzeit ein
> identisches Compilat erzeugbar ist. Andernfalls kann irgendwann der
> Bezug zwischen Sourcen und Compilat unbemerkt verloren gehen.
Aus Platzgründen mache ich so etwas nur bei EINZELNEN Softwareständen.
Wenn sie zum Beispiel an den Kunden rausgehen.
Wenn man es ganz genau macht, müsste man ALLES mit einchecken, inkl.
Compiler. Und ja, ich war schon in Firmen da gab es einen Rechner, für
ein Projekt, mit GENAU DIESEM Softwarestand von vor X Jahren. Alles noch
mit altem Windows XP und dem Stand von damals, gab wohl auch ne
Ausnahmegenehmigung von der IT.
Simon S. schrieb:
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Sowas in der art passt denke ich.
Halte ich auch für sinnvoll, hier und da muss man es eben an die eigene
Arbeitsweise anpassen.
Besonders bei Einsteigern ohne Berufs/Entwicklungserfahrung siehts aber
leider anders aus. Da wird alles erstmal pauschal auf Master gepusht.
Beim nächsten Pull kracht es dann weil jeder am gleichen Stand arbeiten
will (rebase kennen sie dann auch nicht ;-) )