¿Cómo uso las extensiones de Git y Git?

Question

Intro

He usado SVN antes, cuando yo estaba trabajando como programador en solitario, sólo para mantener un registro fuera de las instalaciones de lo que estaba haciendo, así que tipo de saber acerca de las ideas como "depósitos" y "commits" y similares, aunque no mucho más que eso. Las "ramas", las "fusiones" y las "salidas" son, lamentablemente, un misterio para mí.

Quiero comenzar a utilizar Git porque tenemos un par de tipos que trabajan lejos de la oficina y se han quejado de que a veces no pueden acceder a otros sistemas de control de versiones porque su integración IDE les causa enfurruñarse y caerse cuando se pierden de contacto. La idea de Git de "cada directorio de trabajo es un repositorio" parece que debería ayudarnos a resolver eso.

De todos modos, he descargado las "Extensiones de Git" para agregar The Shiny a los menús contextuales de Windows, etc. y he descubierto que realmente no tengo idea de cómo se supone que debo usar esto para controlar mi versionado Al no encontrar nada obvia después de una búsqueda en Google, presento el siguiente escenario teórico de desbordamiento de pila con la esperanza de que alguien me dirá qué hacer, en pequeñas palabras:

Escenario

tengo tres proyectos. Un proyecto, ProjectReuse es utilizado por los otros dos proyectos (ProjectA y ProjectB). Varias personas en la organización deberán editar el código para cada proyecto, usando Visual Studio 2010.

Tengo tres carpetas en mi escritorio, etiquetadas "ProjectReuse", "ProjectA" y "ProjectB". Tengo la ventana Extensiones de Git abierta. Una vaca, con un sombrero de Santa Claus, me mira.

Preguntas

Qué hago ahora para crear los repositorios de tal manera que varias personas (incluyendo los molestos tipos no-siempre-en-sitio) pueden acceder un repositorio cuando necesitan , en el sitio o fuera de él, con o sin una conexión permanente a nuestros servidores?

Cuando el primer chico necesita editar un archivo, ¿qué necesita él hacer? ¿Revisa? ¿Rama? Tengo que explicar esto a los otros miembros del equipo y estoy un poco tambaleante sobre estos conceptos, yo mismo. Solo he usado el control de versiones para mis proyectos en solitario anteriormente.

wheedling y excusas

El primer "¿Cómo fijo esto?" La pregunta es en lo que estoy más interesado, pero creo que si voy a pedir la guía del idiota, también podría pedir que sea lo más útil posible para el siguiente idiota que tropieza con esta pregunta. No estoy buscando respuestas particularmente detalladas, aquí; Simplemente no tengo una idea clara de cómo funciona un sistema de control de versiones multiusuario. Una vez que tengo esto en mente, debería ser capaz de armar el resto por mi cuenta.

Answer 1

Ok, veamos lo primero de git straight. Git se distribuye. Repítelo tantas veces como sea necesario: no hay un servidor central, un repositorio central ni nada central. Completamente en contraste con SVN, no todos están accediendo a un repositorio (nada central).

Lo que hace es crear un repositorio en alguna parte. Entonces todos los demás lo clonan (copian). Ahora todos tienen su propia copia del repositorio y pueden hacer lo que quieran.Los nombres de las sucursales ni siquiera necesitan ser consistentes en todos los repositorios, aunque muchas personas lo hacen porque ayuda.

Entonces, ¿cómo se configura? Inicias un repositorio y luego todos los que lo quieren lo clonan. En su caso, recomendaría que cada proyecto tenga su propio repositorio git en lugar de agrupar los tres juntos.

Pero pero, ¿cómo demonios se supone que debo dirigir un equipo de desarrollo, te oigo decir? Nunca temas. Dije que no había un repositorio central, pero eso no le impide designar uno de los repositorios para ser el depósito de versiones, y otro ser el experimental o lo que sea.

Lo que necesita entonces es un flujo de trabajo. Normalmente, lo que hace es crear dicho repositorio de versiones y luego decir: "todos extraen del maestro aquí". Esto representa su último lanzamiento "estable". Ahora les dice a todos que se ramifiquen desde aquí y desarrollen sus nuevas características. Ellos hacen esto. A medida que se hacen, le pides a las personas que fusionen sus cambios con su propio maestro o donde sea, luego tú, el administrador de lanzamiento, extraes de ellos (probablemente en una rama de desarrollo pero podrías hacerlo en tu release master porque es trivial) para invertir compromisos). La siguiente persona actualiza su master y realiza su fusión. Resuelven sus propios conflictos de combinación, etc., y así hasta que tenga todas las funciones que desea. Haces tus pruebas, etc. luego, el repositorio de versiones realmente extrae todo eso en su maestro.

En la práctica, puede hacer muchas cosas diferentes. Por ejemplo, si tienes mucha gente vas a necesitar mucha comunicación, porque si mucha gente realiza cambios incompatibles en tu proyecto compartido, habrá algunas confusiones de fusión. Para evitar esto, los usuarios pueden jalar/fusionarse entre sí o usar un repositorio "compartido" local.

Funciona.

Answer 2

Como dijo Ninefingers, simplemente inicie un nuevo repositorio y deje que otros lo clonen. Tenga en cuenta que cuando desee un repositorio público (o central), cree un repositorio compartido y no un repositorio privado. La forma más fácil es crear primero un repositorio personal y luego clonarlo en un lugar (por ejemplo, recurso compartido de red) donde todos tengan acceso como repositorio compartido.

he creado un par de tutoriales en vídeo para las extensiones de Git aquí: http://code.google.com/p/gitextensions/ Los tutoriales en vídeo son un poco viejo y no muy bueno, ya que no tengo un micrófono o cualquier habilidades de edición de vídeo, pero debería ser suficiente para conseguir que empezado.

¡Buena suerte!