git Groking uso remoto

Question

He estado 'jugando' con git en mi propia máquina durante 6 meses, y realmente me encanta.

Sin embargo, se me hace difícil asimilar realmente cómo lo usaría en un ambiente de equipo/enterprisey. (Me pregunto si es Eric Sink derecha).

empecé a cabo tratando de instalar un servidor Git en Windows, pero que didn't go too well.

Así que me preguntaba acerca de simplemente configurar un segundo repositorio en mi propia máquina y comenzar a acostumbrarme a tirar/empujar a eso.

¿Conoce alguna buenos artículos para el inicio de 'simple' de esa manera, o tiene algún consejo sobre Grokking al siguiente nivel?

Answer 1

Si:

• su computadora principal es acce ssible a través de un camino compartido (\ myMainComputer \ MySharedDirectory)
• o si tiene varios repo en el mismo equipo

puede simplemente:

• git clone --bare /path/to/your/first/repo
• cd /path/to/your/first/repo
• git remote add bare_repo /path/to/bare/rep
• (trabajo, se compromete)
• git push bare_repo
• (si no han empujado al descubierto repo así)
• git pull bare_repo

En otras palabras, el protocole de archivo es compatible como una URL legítima para repositorios remotos.
Ver git fetch, section URL:

Para los repositorios locales, apoyada también por Git de forma nativa, las siguientes sintaxis se pueden utilizar:

/path/to/repo.git/ 
file:///path/to/repo.git/ 

Answer 2

Probé Git Magic, que fue lo primero que leí al aprender Git, y que fue genial para ayudarme a entender lo que estaba haciendo - el capítulo 3 trata sobre el manejo de más de un repositorio.

Answer 3

Usted puede leer algunos artículos sobre Git flujo de trabajo diario, y me gustaría recomendar dos:

• http://geewax.org/2009/11/21/agile-git-workflow.html, flujo de trabajo git ágil
• http://nvie.com/git-model, éste está a punto de ramificación y la cooperación

Answer 4

This es el flujo de trabajo que trato de mantener, con guiones para facilitar este flujo de trabajo dado here.La idea básica es tener al menos dos repositorios:

(a) un repositorio remoto general "central", que sirve como el repositorio canónico "primario" para todos los desarrolladores; el código insertado aquí siempre debe ser (más o menos) ininterrumpido y funcional, pasar todas las pruebas, etc.

(b) repositorio remoto personal "trabajo en curso"/desarrollo, que sirve como respaldo remoto para el desarrollo local o sub-equipo. El código aquí puede estar en cualquier estado. Aprovechando al máximo la ramificación barata de Git, generalmente la línea de desarrollo del tema de wip debería estar en sus propias sucursales (como se describe en los enlaces anteriores), hasta que esté listo para el horario de máxima audiencia. Cuando llegue el momento, conéctese con su maestro local y luego envíe esto al repositorio "primario" y elimine las ramas de protección de sus repositorios de desarrollo remotos tanto locales como personales.

Opcionalmente, es posible que desee un tercer repositorio, para consumo público (es decir, sin equipo del proyecto).

También le recomendamos que busque here para obtener una descripción de un flujo de trabajo similar pero diferente. Por cierto, el libro de Pro Git dado en el enlace anterior es, en mi opinión, el mejor recurso de Git actualmente disponible.