3. Welches SCM benutzt ihr?

Welches SCM benutzt ihr?

  • N

    DEvent schrieb:

    Ein paar Sekunden? Wie groß ist den euer Projekt? Den größten merge hatte ich etwas über 1500SLOC add/remove, das war in einem Wimpernschlag erledigt.

    Ich meinte inklusive "Shell suchen, 'git merge …' tippen" bzw. "GUI öffnen, Merge anstoßen".

    0
  • N

    Ein großes Missverständnis: Git ist kein "dezentrales" VCS. Git ist ein "verteiltes" VCS. Dh. Git _kann_ dezentral verwendet werden, Git kann aber auch in ganz klassischen zentralisierten Setups benutzt werden, oder auch in Mischformen, auf die ohnehin schon einige Male eingegangen wurde.

    ;fricky schrieb:

    also alles wie gehabt, nur dass das, was bei SVN 'commit', bei git 'push' heisst und SVNs 'update' heisst unter git 'rebase' oder so ähnlich.

    Nein, commit bei Subversion entspricht bei Git commit+push, allerdings kannst Du commit eben auch nur lokal benutzen, ohne sofort zu pushen.
    Das, was bei SVN update heißt, ist bei Git "pull", was das selbe macht wie "fetch+merge" (also Änderungen holen und gleich mergen).
    Ich bin mir ziemlich sicher, dass Du nicht verstanden hast, was "git rebase" macht, SVN hat auch nichts entsprechendes soweit ich weiß.

    0
  • ?

    DEvent schrieb:

    Das versucht man einem die ganze Zeit zu erklären, dass du Git wie SVN benutzen kannst, ohne die ganzen Nachteile von SVN. Aber jeder denkt, dass man ein distribute SCM nur dezentral, ohne Server, benutzen kann.

    naja, dass man git wie ein gewöhnliches, serverbasiertes VCS benutzen kann, wird durch eure ständigen lobhudeleien auch nicht besonders deutlich. ich war z.b. bis gestern noch der meinung, dass es sich bei git um ein hochintelligentes verteiltes system handelt, das alle kopien desselben repositories auf 'magische weise' selbst synchronisiert. in wirklichkeit sieht's wohl doch so aus, dass git oft in zusammenhang mit einem zentralen master-repository eingesetzt wird, das sich auf 'nem server befindet.

    nman schrieb:

    stimmt allerdings, aber wenn du offline versionskontrolle brauchst, tut's ja ein lokales VCS, wobei du dann wieder vor den gleichen problemchen stehst, wie mit allen lokalen kopien: wenn die pestflatte den geist aufgibt, oder dein schlepptopp geklaut wird...

    Aber als genau so ein "lokales VCS" fungiert doch Git:
    - Jedes Verzeichnis in dem ich "git init" mache, ist ein Git Repo.
    - Dieses Verzeichnis kann ich dann auch überall hinpushen bzw. Leute von mir klonen und pullen lassen oä.
    - Dh. ob Du Offline oder Online bist, ist völlig egal, Du hast immer das Repo, mit dem Du normalerweise arbeitest zur Verfügung. Und sobald Du das nächste Mal "push" machst, sind Deine Daten meinetwegen auch auf dem bestens gesicherten und gebackupten zentralen Server.

    ^^ich meinte ja auch ein beliebiges VCS, das lokal installiert wird. ähnliches bekommst du auch mit 'svnsync' hin, aber vermutlich isses hierbei nicht ganz so flexibel wie git.
    🙂

    0
  • B

    Werde mir Git demnächst mal anschauen, halte es aber für schwierig, bestehende Projekte zu migrieren. Dafür muss erstmal die Bereitschaft jedes einzelnen Entwicklers da sein. Man müsste also erstmal sehr viel Überzeugungsarbeit leisten, um von einem SVN auf Git zu wechseln. Das ist imo auch der Grund, warum SVN immernoch so weit verbreitet ist.

    0
  • D

    byto schrieb:

    Werde mir Git demnächst mal anschauen, halte es aber für schwierig, bestehende Projekte zu migrieren. Dafür muss erstmal die Bereitschaft jedes einzelnen Entwicklers da sein. Man müsste also erstmal sehr viel Überzeugungsarbeit leisten, um von einem SVN auf Git zu wechseln. Das ist imo auch der Grund, warum SVN immernoch so weit verbreitet ist.

    Dafür gibt es auch git-svn. Du hast ein SVN Repository, kannst aber alle Git Befehle benutzen.

    git-svn - Bidirectional operation between a single Subversion branch and git

    0
  • B

    Interessant. Aber wir benutzen SVN eigentlich nur über die IDE (derzeit Eclipse). Werde demnächst auf Intellij IDEA umsteigen und dort dann mal den Git Support testen.

    Bei Intellij IDEA gibt es ein einheitliches UI für alle VCS, die unterstützt werden (SVN, CVS, Git und mehr). Insofern wäre die Umgewöhnung womöglich recht einfach.

    0
  • N

    ;fricky schrieb:

    naja, dass man git wie ein gewöhnliches, serverbasiertes VCS benutzen kann, wird durch eure ständigen lobhudeleien auch nicht besonders deutlich. ich war z.b. bis gestern noch der meinung, dass es sich bei git um ein hochintelligentes verteiltes system handelt, das alle kopien desselben repositories auf 'magische weise' selbst synchronisiert.

    Hm… Dass sich Git für stinknormale zentralisierte Setups benutzen lässt, wird eigentlich auf allen verlinkten Seiten und wohl sogar im Wikipedia-Artikel sehr früh erwähnt. Woher Du die Idee mit dem magischen selbst synchronisieren hast, weiß ich nicht, da muss man ja auch misstrauisch werden. 🙂

    ^^ich meinte ja auch ein beliebiges VCS, das lokal installiert wird. ähnliches bekommst du auch mit 'svnsync' hin, aber vermutlich isses hierbei nicht ganz so flexibel wie git.
    🙂

    Der Unterschied ist unter anderem der, dass "lokale Installation" bei Git bedeutet, dass Du Deinen Paketmanager oder den Installer anwirfst und eben nicht irgendwie groß Repos administrieren musst, wie bei nicht verteilten VCS.

    Und dass svnsync eine ziemlich gewaltige Krücke ist, weißt Du ja selbst. 🙂

    0
  • ?

    byto schrieb:

    Werde mir Git demnächst mal anschauen, halte es aber für schwierig, bestehende Projekte zu migrieren. Dafür muss erstmal die Bereitschaft jedes einzelnen Entwicklers da sein. Man müsste also erstmal sehr viel Überzeugungsarbeit leisten, um von einem SVN auf Git zu wechseln. Das ist imo auch der Grund, warum SVN immernoch so weit verbreitet ist.

    klar, solange SVN tut was es soll, sehen viele keinen grund zum umstieg. ich würde mich auch damit schwertun, ausser vielleicht, ich dürfte öfters mal tagelang programmieren, ohne dass eine internetverbindung in reichweite ist.

    byto schrieb:

    Interessant. Aber wir benutzen SVN eigentlich nur über die IDE (derzeit Eclipse). Werde demnächst auf Intellij IDEA umsteigen und dort dann mal den Git Support testen.

    hihi, intelliJ hat doch schon sein eigenes mini-VCS eingebaut, das bei jedem compile/build, run/debug und refactorings usw. automatisch committed. ein paar tage loggt das auch alle änderungen mit (irgendwann fliegen wohl die ältesten raus). da brauchste wohl kein zweites lokales VCS, das alle entwicklungsschritte mitspeichert. ein repository auf einem server ersetzt das natürlich nicht.

    nman schrieb:

    Woher Du die Idee mit dem magischen selbst synchronisieren hast, weiß ich nicht, da muss man ja auch misstrauisch werden.

    ich hab's mir eingebildet, aber die vorstellung finde ich nicht schlecht. vielleicht gibt es sowas ja schon (oder irgendwann mal).
    🙂

    0
  • B

    Es gibt eine Local History (hat Eclipse übrigens auch). Das würde ich aber nicht als vollwertiges lokales VCS bezeichnen.

    SVN hat definitiv Schwächen beim Mergen zwischen verschiedenen Branches. Und Branching allgemein könnte auch besser sein. Wenn ich z.B. einen neuen Branch erzeuge, dann muss ich erst umständlich in Eclipse einen neuen Workspace anlegen und den Branch auschecken. Änderungen aus dem Branch dann in den Trunk zu mergen ist auch recht umständlich. Man hat sich mit der Zeit halt damit arrangiert.

    0
  • B

    Mich wuerd mal interessieren wie granular eure git commits sind? commitet ihr nur fertige Features oder auch Zwischenschritte? Halbfertige Zwischenschritte?
    Und falls ihr mehr als nur komplette Features commited: gehen die nur in die branch, in die ihr grad arbeitet (bzw. ins lokale Repo), und werden danach zu einem einzelnen kommit fuer den localen master (globalen Master) gesquashed?
    Wie handhabt ihr sowas?

    0
  • E

    Ich hatte es glaub ich schon geschrieben.
    Ich entwickel in einem dev Branch, und submitte immer wenn ich den PC aus mache, egal ob es fertig ist oder nicht, auch egal ob es überhaupt baut.
    Immer wenn dann ein Feature fertig ist, Merge ich es nach main und label dort zusätzlich.
    So habe ich in main die letzte Stable und in dev das aktuellste.

    0
  • M

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.

    0
  • D

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    Ich habe ebenso einen Dev. branch, devent und commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles in master und pushe es zum Server.

    0
  • M

    DEvent schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    Ich habe ebenso einen Dev. branch, devent und commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles in master und pushe es zum Server.

    Und was, wenn du mehrere Feature-Branches hast? Gibts dann eine devent.<FEATURE> Branch für jedes Feature?

    0
  • D

    Mr. N schrieb:

    DEvent schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    Ich habe ebenso einen Dev. branch, devent und commite nach jedem fertigen Zwischenschritt. Wenn ich fertig bin, merge ich alles in master und pushe es zum Server.

    Und was, wenn du mehrere Feature-Branches hast? Gibts dann eine devent.<FEATURE> Branch für jedes Feature?

    Oder einfach <FEATURE> . Man braucht kein Namespace für Git. devent ist halt mein Dev.-Branch.

    0
  • M

    DEvent schrieb:

    Oder einfach <FEATURE> . Man braucht kein Namespace für Git. devent ist halt mein Dev.-Branch.

    Ja, aber benutzt du die devent-Branch auch für Entwicklung in Feature-Branches? Das wird ja eigentlich wohl kaum gehen... Also musst du entweder direkt in der Feature-Branch entwickeln, oder eine eigene Dev-Branch für die Feature-Branch einrichten.

    Aber ehrlich gesagt halte ich ohnehin nichts von Dev-Branches. Ich habe hier eine master-Branch und viele Feature-Branches. Und für alte Release-Serien eben Release-Branches bei Bedarf (also wenn z.B. 0.10 aktuell ist, gibt es eine release-0.9 Branch für die Entwicklung der 0.9.x Serie).

    0
  • B

    Mr. N schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.

    aber hast dann nicht ein furchtbar unuebersichtliches log/history?

    BTW: loescht du feature-branches, wenn sie fertig implementiert sind, oder behaelst du sie bei (oder verwendest sie gar weiter)?

    0
  • D

    Blue-Tiger schrieb:

    Mr. N schrieb:

    Blue-Tiger schrieb:

    Mich wuerd mal interessieren wie granular eure git commits sind?

    So klein wie möglich. Allerdings nur so granular, dass ich nicht ständig git add -p oder -i verwenden muss. Gesquasht wird nicht, oder nur extrem selten.

    aber hast dann nicht ein furchtbar unuebersichtliches log/history?

    Ein Log sollte doch dokumentieren welche Änderung wieso gemacht wurde. Da sind viele kleinere commits doch besser als ein großer commit?

    0
  • B

    DEvent schrieb:

    Ein Log sollte doch dokumentieren welche Änderung wieso gemacht wurde. Da sind viele kleinere commits doch besser als ein großer commit?

    Na ja, kommt drauf an. Ich denk mir halt, ein commit das 7 Dateien umfasst und dessen commit-messageueberschrift "implemented document saving functionality" uebersichtlicher als 6 Commits mit "Added SaveCommand class." "connected SaveCommand with GUI." "fixed Bug in SaveCommand & iostreams." "redesigned SaveCommand to work with different iostreams." "Changed gui icon for saving." "fixed GUI bug".

    Alternativ koennt man ja einen "savecmd"-branch machen, da wirklich "detailiert" committen, aber dann halt beim merge squashen. Zerstoert zwar die Tree-Struktur, dafuer bleibt das log vom head schoen uebersichtlich.
    Aber ich hab kaum Erfahrung mit git, deswegen wollt ich mal nachfragen wie andere das handhaben und ein Gespuehr von den "git best practices" zu kriegen.

    0
  • M

    Blue-Tiger schrieb:

    aber hast dann nicht ein furchtbar unuebersichtliches log/history?

    BTW: loescht du feature-branches, wenn sie fertig implementiert sind, oder behaelst du sie bei (oder verwendest sie gar weiter)?

    Das Log ersetzt keine ChangeLog.txt, von daher sehe ich da kein Problem. Kleine Commits haben eben viele andere Vorteile, gerade für Dinge wie Cherry Picks und Fehlersuche.

    Ja, ich lösche Feature-Branches, wenn sie in master sind, meistens.

    0
Anmelden zum Antworten