¿Cuál es la mejor manera de usar GIT en nuestro entorno de trabajo?

Actualmente no usamos ningún tipo de software de control de versiones. Recientemente comenzamos a usar Eclipse, y nuestro código fuente se mantiene en una unidad de networking. Se creó un proyecto de Eclipse y todos han importado el proyecto a Eclipse en sus máquinas. Debido a la forma en que estamos configurados, siempre nos estancamos en circuitos limpios / de construcción durante todo el día, lo que perjudica la productividad.

Nos gustaría comenzar a usar algún tipo de VCS (probablemente GIT). Estoy visualizando un flujo de trabajo centralizado en el que cada desarrollador tendrá una copy local del código en su máquina. Preferimos usar GitHub Enterprise para el repository compartido en lugar de alojar el código en GitHub.

No estoy seguro de por dónde empezar para get esta configuration correctamente. He estado viendo videos y leyendo tutoriales, sin embargo, ninguno parece aplicarse directamente a cómo nos gustaría hacer las cosas. ¿Es GIT el software adecuado para usar para el tipo de configuration que deseamos? Además, ¿cómo funciona clean / building con Eclipse y las copys locales frente al repository compartido?

Primero, mira este video .

Segundo, si estás usando Eclipse, vas a usar EGit . Un tutorial muy detallado aquí .

En tercer lugar, no te metas en GIT. Considere SVN en algún momento (después de documentar en GIT). Quizás un Sistema de Control de Versión Central lo hará mejor que un Sistema de Control de Versión Distribuida.

Editar:

Ah, y por cierto … hay muchas preguntas y respuestas largas y famosas aquí con respecto a este tema. La mejor de las suertes.

Segunda edición:

En cuanto a SVN , aquí tienes un tutorial fácil sobre Subversivo , y aquí puedes encontrar la documentation subversiva completa en tu cara.

Ahora tiene sus necesidades, pero sus necesidades cambiarán. Ahórrese el dolor de cabeza de mudarse más tarde a Git desde SVN y comience con Git. Aquí están las razones para ir con Git sobre Subversion:

  1. Velocidad – Git es MUCHO más rápido
  2. Espacio en disco: el historial de Git es pequeño . La mayor parte del time ocupa 1 / 10th del espacio del historial de SVN.
  3. Sin server: DVCS no permite administrador y puede omitir un server centralizado por completo. Su repository central solo puede ser files en un recurso compartido de networking.
  4. Integridad: corrupción de datos muy fácil de detectar y corregir.
  5. Historial de instantáneas: todo el proyecto se toma instantáneamente para cada versión. Sin mezclar y hacer coincidir las routes con las versiones.
  6. Dependencias de código abierto: la mayoría de los proyectos que quiera usar están en Github. Simplemente puede agregar un submodule y versión de esa dependencia.
  7. Poder:
    • git bisect: encuentra un lugar donde se introdujo un error rápidamente
    • Rerere: reutiliza cómo resolviste los conflictos si vuelven a aparecer
    • admite cualquier flujo de trabajo
    • fusiones correctas de 3 vías: esto ahorrará una tonelada de dolores de cabeza en el futuro
    • rebase: puede mantener su historial lineal, incluso después de que alguien se fusionó

Mi último punto es muy importante. Acaba de comenzar a usar el control de fuente. Comience con la mejor opción. Estás en un punto donde sabes lo mínimo sobre tus necesidades. Las cosas que crees que no necesitas ahora las necesitarás más tarde, garantizadas.

Crearía un repository git en la unidad compartida , no necesitas un server como github en absoluto. Después de configurarlo, los desarrolladores pueden clonar desde la unidad compartida a su computadora local y rechazar los cambios cuando terminen.

Cada desarrollador terminará con una copy local del código donde tienen su propio entorno de construcción y nunca más estarán en el path de los demás.

Comience con un proyecto de ejemplo con solo algunos files y juegue con él, ya que necesitará get experiencia con un sistema de control de versiones. También aprenda las herramientas de command-line de git (para Windows use msysgit ), porque la mayoría de los ejemplos en Internet están escritos para eso. Para get más información sobre git, asegúrese de leer el libro gratis de git: http://git-scm.com/book

También vea esta pregunta sobre el uso de git en un recurso compartido de Windows: ¿Cómo hacer clonar un repository en Windows desde otra PC dentro de la LAN?

Como algunos ya notaron, para la pregunta

la mejor manera de usar GIT?

en su situación (cero experiencia SCM) la mejor y más imparcial respuesta será

¡No uses Git para nada!

Al contrario de "¿Por qué Git es mejor que Subversion?" tema que también puede leer (algunos subsets como resultado de la recuperación rápida)

  • GIT – ¿Qué problemas deberían tener en count los recién llegados al control de versiones?
  • ¿Qué hace SVN mejor que git?
  • ¿Cuáles son los requisitos previos para aprender y entender a Git?

y revisa otros temas bajo la label git con múltiples lamentos de Git-boys.

Aunque Subversion es una opción bastante buena (con algunas esquinas de todos modos: puedes caer en "Merge Hell" incluso si piensas en el desarrollo como lineal: algunas twigs pueden y deben suceder, en "Refactoring Nightmare" con el famoso error "Tree conflict" …) puede pensar en alternativas "Usables como Subversión y potentes más que Git" (incluso solo usará una pequeña parte necesaria o potencia general): – DVCS Mercurial con rostro humano, hecho por ingenieros de software para ingenieros de software , no para los types de moda ".

  • MercurialEclipse es la respuesta para la request de Eclipse (en la recomendación de Aragost, los usuarios de Mercurial confían)
  • TortoiseHG es una interfaz gráfica de usuario multiplataforma fácil de usar para todos y cualquier necesidad de Mercurial fuera de Eclipse
  • El server Mercurial requiere mucho less dolor de cabeza (especialmente "bajo Windows"), que el server Git equivalente
  • Los expertos reales de Mercurial pueden ser encontrados fácilmente (mientras que los Git-boys son más divertidos-club de adolescentes entusiasmados)

EGIT para eclipse es el mejor para integrar git en tu entorno de proyecto de eclipse.

Además, si está en Windows, puede download Github para Windows , es realmente simple, efectivo de usar.

GIT es sin duda la forma preferida y se integra muy bien con Eclipse IDE. Pero también podría usar Subversion ya que todo lo que desea es una copy local del código en la máquina del usuario (llámelo twig de subversión). Digo la forma preferida porque GIT es demasiado flexible: compromisos sin connection, copy completa del cuerpo del código versus solo twig, etc. … la list es demasiado larga.

Como mencionaste, también puedes usar github. A grandes rasgos, los pasos son los siguientes:

  1. Solo regístrate para ello
  2. crea un repository
  3. Obtenga el enlace al repository y señálelo como el nuevo repository de git en Eclipse
  4. Empuja tu código Comprométalo

Tendrás tus files de código en github. Esto funcionará siempre que tenga instalado Git en Eclipse. Creo que Eclipse Juno ya está configurado con EGit (complemento para Git)

Para resolver los problemas de compilation, puede usar la configuration de algunas herramientas de continuous integration como Jenkins. Esto también se puede configurar como un plugin de Eclipse.