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.
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.