spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja das meinte ich, aber wenn es dafor schöne GUIs gibt es ja ok.
In git sieht man ja die Kopien nicht. Da ist das ja alles schön versteckt (:

Hm? Du siehst in SVN auch nicht, dass der Branch bloß eine cheap copy ist.

Ich muss ganz ehrlich sagen, dass ich GIT definitiv nicht als simpel oder einfach bezeichnen wuerde.

Natuerlich ist es einfach wenn man nur init/commit verwendet. Sobald man ein wenig mehr macht wird Git sehr komplex und kleine Fehler in den Befehlen koennen einem ganze Branches kaputt machen, und spaetestens dann muss man sich mit der Komplexitaet von Git beschaeftigen. Es hat gut ein halbes Jahr gedauert bis Git mir nicht mehr "im Weg stand", doch selbst heute sind viele Dinge die in Git passieren noch magic fuer mich.

Dot: Ich kann nicht viel ueber die Speicherplatz Effizienz sagen, was mir jedoch angenehm aufgefallen ist, dass ich nie auf einen git Befehl warten muss. Selbst rebases zwischen stark divergierten Branches oder checkouts von selbigen sind verdammt flott. Auch in grossen Repositories wie dem Linux Kernel.

Man muss sich natürlich etwas auf Git einlassen um es ordentlich zu verwenden. Wer anfängt an der History rum zu fummeln und es dann auf Git schiebt, dass Konflikte auftreten, ist die Sache definitiv falsch angegangen. Um relativ konfliktfrei mit Git zu arbeiten, bieten sich feste Workflows wie git-flow an.

Ich möchte da auch nochmal Source Tree als Git GUI hervorheben. Bei Source Tree ist die git-flow Unterstützung direkt mit eingebaut und es lässt sich auch ohne große Git Kenntnisse mit Develop-, Feature-, Release-, und Hotfix-Branches arbeiten. Auch Submodules lassen sich per GUI einbinden und verwalten.


Ich habe bei meiner Diplomarbeit, dank git-svn, sogar einen Git Workflow mit SVN Repo im Hintergrund verwendet. Git-SVN ermöglicht das clonen eines SVN Repos (komplett oder nur ein Teil der History). Danach kann man damit wie mit einem normalen Git Repo arbeiten. Ein remote Push sorgt dann auch wieder dafür, dass die Git Commits ins SVN übertragen werden. Ich habe dann Git während der Entwicklung und es Testens verwendet, vor allem um PC, Laptop und Uni-Server zu synchronisieren. Ins SVN kamen dann die bereinigten Commits.

Zitat von »dot«

Soso? Meines Wissen nach speichert git die Daten im Repository nicht in Form von deltas, sondern jede Version jeder Datei als ganzes, nur komprimiert. Das geht dann natürlich schnell, weil git, im Gegensatz zu anderen Systemen, so natürlich nur komprimieren und keine aufwändigen diffs erstellen muss, hört sich mir alles andere als nach einem effizienten Repository-Format an. Insbesondere würde mich interessieren, wie gut das mit Binärdaten funktioniert. In meinen Projekten hab ich sehr oft große Mengen an Binärdaten (3D Modelle, Texturen, Videos, ...). Mit SVN kein Problem, wie gut kann git mit sowas umgehen?

Git verwendet zur Speicherung der Daten auch Deltas. Allerdings werden diese erst nach gewisser Zeit, auf Wunsch (git gc) oder bei Bedarf (z.B. beim Push) erzeugt.

Zitat von »Fetze«

Da die Diskussion ja nun zum Erliegen gekommen zu sein scheint, erstmal ein Danke für all eure Antworten - das hat mir schonmal einen gewissen Eindruck verschafft. Insbesondere http://www.atlassian.com/git sieht nach einer recht guten Seite für den Einstieg aus und GitHub wirkt als Plattform recht solide. Als Client werde ich mir http://www.sourcetreeapp.com/ mal downloaden, das wirkte vom Ersteindruck her relativ vertrauenserweckend. Sobald ich dazu komme, werde ich mir das dann wohl doch mal näher ansehen

SourceTree ist eine sehr gute Wahl! Ich wuerde es auch benutzen wenn ich nicht ueber SSH arbeiten muesste