Nosotros usamos Sourcetree + github. El límite de 2GB lo pasamos en un proyecto mediano con carga de assets (3D + texturas) y varias ramas en un par de ocasiones. Para proyectos pequeños, con 2GB tienes de sobra. El problema es que git no está pensado para binarios/assets, así que en cuanto le metas algo diferente a texto/código, pierde parte de su potencial.
Hoy en día, SVN para código evítalo. Un merge con git (o mercurial) es mucho más fácil, no tardas na en hacer ramas, y el flujo de trabajo lo agradece.
Por si te "inspira", mi planteamiento en futuros proyectos será tratar de quitar los assets de git y sacarlos a Dropbox, por ejemplo, o SVN incluso. Dropbox porque para los artistas es más cómodo (sincronización automática, no hay que preocuparse de ramas ni leches, y así la culpa es sólo de ellos :p)
Para dividir el curro: creo que tu pregunta no va por cómo dividir el repo, si no el trabajo en sí. Depende del equipo, pero veo importante que, si tenéis la idea del flujo del juego, lo implementéis antes, y luego os centráis en el núcleo del juego.
Es decir, uno hace el menú principal, con el botón para empezar a jugar, que carga una escena en "blanco" y luego se carga el final de partida y se vuelve al menú (ciclo completo). Otro se pone a hacer la pantalla de juego, que es un paisanín que se mueve y gana automáticamente al llegar a una caja a 2 metros a la derecha. Integráis y ya tenéis un "juego completo" cuando pulséis en crear la build.
Luego, os ponéis los dos con el juego. Decidís cómo estructuraréis la interacción jugador-enemigos (capas que se utilizan para plataformas, para enemigos y el personaje y otros aspectos generales del juego). Uno pule los controles para el prota, y otro hace el enemigo más básico que haya en el juego, aunque esté quieto. Integráis, lloráis con los primeros problemas de conflictos si los hay, y váis avanzando teniendo desde el primer punto un flujo completo de juego, que creo que lo agradeceréis más adelante.
Ya nos cuentas qué tal te fue. Saludos!
