git oder hg, micro commits und history

Hi,

hätt eine Frage bezüglich git oder mercurial.

ist es möglich zu einem Project 2 repositories zu haben, das an dem gearbeitet wird, mit den micro commits wie zB
feature x begonnen
feature x fertig
docu gemacht,
fehler in docu ausgebessert

in einem eigenen branch,

und eines welches nur die Hautversionen hat und die history dann so aussieht

feature x dazu.

und die privaten branches der entwickler mit den micro changes bleiben in deren repositories

ist soetwas überhaut möglich?

kurze_frage schrieb:

ist soetwas überhaut möglich?

Ja. (Stichwort --squash)

SG1

Wobei man dazu sagen muss, dass das dann 2 komplett getrennte Repos sein müssen. Von dem einen zum anderen pushen geht dann nicht mehr.

es soll keiner pushen, nur pullen.

die basis idee für den workflow ist

main repo

devs ziehen ihre Version
microcommits, habe fertig

main repo pulled nur den letzten stand von habe fertig von den devs,
merged das zusammen, + tests + ... macht neue version

devs pullen auf letztstand
machen wieder ihre experimente, wenns was wird zum verwenden dann ..

ich hab das mit hg proobiert bin aber gescheitert, viellecht sollt ich mal git probieren

SG1

Die Frage ist: sollen die Devs auf ihren Rechnern jeweils die kleinen Commits behalten? (Les ich irgendwie so raus, als ob Du das so haben willst - mag mich aber auch irren). Wenn ja, dann geht das auch mit git nicht.

SideWinder

Du kannst den Merge in den anderen Branch doch jedes Mal beim Namen nennen, niemals FastForward verwenden und in einem graphischen Tool nur den Release-Branch einblenden. Schon sollte man die geforderte Historien-Ansicht haben.

BTW @ kurze_frage: Komplett getrennte Repos verlängern nur die Release-Dauer, das ist schlecht. Bei einigen Tests am Release-Repo wird es zu Fehlern, etc. kommen, da heißt es dann möglichst schnell stabil zu werden -> nur möglich wenn die Devs sofort und ohne Umstände das fixen können.

MfG SideWinder

die Sache ist die

Entwickler sollen gerne mal einen Branch anfangen und was ausprobieren.
wenn es nicht funktioniert soll das nicht verworfen werden

im main repository, welches dann viellcheit mit externen geteilt, oder aus anderen Gründen, brauchen solche zukünftigen Ideen und sonstiges nicht drinnen sein.

weiters gibt es unterschiedliche Entwickler,
manch machen millionen micro commit und rebasen das nie
andere probieren eine art change history zu haben, nur super tolles fertiges wird comitted ,viele zwischeschritte / später nützliche fehlversuche verschwinden im nirvana.

entwickler solln unter einander machen was sie wollen aber alles soll aufgehoben werden und die change history mentalität legen einige leichter ab wenn sie wissen das ihre fehlversuche eh nie 'public' werden.

daher Repos welche quasi im Letztstatus des Main Branch Code gleich sind bzw abgeglichen werden, aber nicht history gleich.

master pulled von entiwcklern ihren status, macht merge und extra tests,
wenn neue version gelabled,
entwickler pullen version in ihr local repo und mergen zurück.

mehr arbeit ist egal
mur wie kann ich das erreichen?
(ich hoffe ich habe jetzt mein Problem jetzt verständlich erklärt)