Como desarrollador único (por ahora), ¿cómo debo usar Git? [cerrado]

53

Tengo varios proyectos en Git a los que eventualmente quiero atraer a otros. Sin embargo, ahora solo soy yo y uso Git y GitHub de manera muy simple: no hay sucursales y, básicamente, solo uso las confirmaciones como respaldo de mis archivos locales. A veces vuelvo y miro las versiones anteriores de mis archivos para referencia, pero no he necesitado hacer ninguna reversión hasta este punto, aunque aprecio la opción si la necesitara en el futuro.

Como desarrollador único, ¿qué características de Git o GitHub puedo aprovechar que me beneficiarían ahora? ¿Cómo debería ser mi flujo de trabajo?

Además, ¿hay alguna práctica en particular que deba comenzar a realizar antes de agregar otros a mis proyectos en el futuro?

    
pregunta VirtuosiMedia 13.10.2011 - 22:55

4 respuestas

58
  

Además, ¿hay alguna práctica en particular que deba comenzar a realizar antes de agregar otros a mis proyectos en el futuro?

Por supuesto. Existe una buena práctica simple que puede usar incluso si no tiene un equipo en este momento: crear una rama separada para el desarrollo. La idea es que la rama maestra contendrá solo versiones de código liberadas o cambios importantes. Esto puede ser adoptado fácilmente por los nuevos desarrolladores que se unen a su proyecto.

Además, la bifurcación es útil incluso si está trabajando solo. Por ejemplo, encuentra un error mientras está codificando una nueva característica. Si no usa sucursales, tendrá que hacer ambas cosas: agregar nuevas funciones y corregir el error en la misma rama. Esto no es bueno: P Por otro lado, si ha creado una nueva rama para crear su nueva función, puede retirar la rama de desarrollo, corregir el error y devolver la nueva rama de características.

Este es solo un breve ejemplo de lo que puedes hacer siendo un único programador. Estoy seguro de que debe haber más buenas prácticas.

Le recomiendo este artículo: Un modelo exitoso de ramificación Git

    
respondido por el Cristian 13.10.2011 - 23:27
13

Estoy exactamente en esta situación, pero opté por un flujo de trabajo un poco más complejo, aunque no necesariamente más complicado, con Git.

El objetivo al principio era aprender el modo git, así que exploré un poco. luego volvió al flujo de trabajo que describió.

Después de un tiempo, fue difícil trabajar con él, ya que surgieron algunas situaciones que también me dieron malos hábitos que serían difíciles de romper una vez que me uniera a un equipo.

así que me conformé con lo siguiente:

  • Repositorio local para trabajar.
  • Rama maestra como un tronco estable para la aplicación
  • Una rama para cada función / refactor, básicamente una rama para cada cambio importante que se realizará.
  • Combinar de nuevo al tronco cuando la rama es estable y todas las pruebas pasan.

También configuro una cuenta de git hub donde sincronizo el troncal. Esto me permitió comenzar a trabajar fácilmente en diferentes computadoras. Fue por necesidad, pero me permitió encontrar errores que estaban relacionados con el entorno en el que estaba y que no estaba disponible en las otras computadoras. Así que ahora me acostumbro a probar un proyecto en un sistema "virgen" diferente al menos una vez. Me ahorra muchos dolores de cabeza cuando llega el momento de implementarlo en el cliente.

  • Etiqueto todas las versiones que lo convierten en github como una versión liberable.
  • Si se entrega al cliente, me desviaré de esta versión para crear un segundo enlace estable para las correcciones de errores declaradas por el cliente.

Las múltiples ramas al principio parecían excesivas, pero REALMENTE ayudó mucho. Podría comenzar una idea en una rama, trabajar en ella por un tiempo y cuando comienzo a hacer círculos, me di por vencido y comencé a trabajar en otra rama. Más tarde, surgió una idea en la que volvería a la rama a medio hornear y exploraría esta idea. En general, esto me hizo MUCHO más productivo, ya que podía actuar con destellos e ideas muy rápidamente y ver si funcionaba. El costo de cambiar de sucursal con GIT es extremadamente bajo, lo que me hace muy ágil con mi código base. Dicho esto, todavía tengo que dominar el concepto de rebase para limpiar mi historia, pero como estoy solo, dudo que realmente lo necesite. Lo empujó como "agradable de aprender".

Cuando toda la ramificación se complicó, exploré la opción de registro para dibujar un árbol de cambios y ver qué rama está donde.

En pocas palabras, git no es como SVN, CVS o (brrr) TFS. La ramificación es muy barata y cometer errores que eliminarán el trabajo es bastante difícil. Solo una vez perdí algo de trabajo y fue porque hice mis compromisos demasiado grandes (ver los malos hábitos arriba). Si te comprometes a menudo, git pequeños serán definitivamente tu mejor aliado.

Para mí, git me abrió la mente de lo que realmente se trata el control de fuente. Cualquier otra cosa antes era solo intentos de conseguirlo, git es el primero, en mi opinión, lo tengo. Dicho esto, no probé otro DVCS, posiblemente esta declaración podría ampliarse a toda la familia.

Un último consejo, la línea de comando es tu amigo. No quiero decir que las herramientas gráficas no sean buenas, sino todo lo contrario, pero realmente me molesté cuando caí a la línea de comandos y lo probé yo mismo. En realidad está muy bien hecho, es fácil de seguir con un sistema de ayuda muy completo. Mi mayor problema fue estar atado a la pero fea consola de Windows hasta que encontré alternativas.

Ahora uso ambas, la integración de Eclipse con Git para ver lo que está sucediendo en tiempo real y hacer algunas operaciones como diffs, explorar el historial de un archivo, etc. árboles de troncos complejos. algunas secuencias de comandos básicas y nunca he sido tan productivo con respecto al control de origen y nunca tuve tanto control sobre mi origen.

Buena suerte, espero que esto haya ayudado.

    
respondido por el Newtopian 14.10.2011 - 04:01
4

Estoy bien versado en varios modelos de ramificación sofisticados, y uso algunos en el trabajo. Sin embargo, cuando trabajo solo en proyectos, hago casi exactamente lo que estás haciendo ahora. Siempre puedo crear una rama después del hecho si la necesito, pero casi nunca lo hago. Trabajando solo, rara vez tengo correcciones de errores que no pueden esperar hasta que termine mi tarea actual. Mi consejo es estar familiarizado con algunos modelos de bifurcación, pero no tiene sentido complicar las cosas hasta que lo necesite.

    
respondido por el Karl Bielefeldt 14.10.2011 - 01:58
2

Para un modelo más simple, puedes ver lo que hace GitHub. "GitHub flow" es muy simple, y hay una excelente guía aquí: enlace

Resumen (de blog de Scott Chacon ):

  

Entonces, ¿qué es GitHub Flow?

     
  • Cualquier cosa en la rama maestra es desplegable
  •   
  • Para trabajar en algo nuevo, cree una rama con nombre descriptivo fuera del maestro (es decir: new-oauth2-scopes)
  •   
  • Comprométase con esa sucursal localmente y envíe su trabajo regularmente a la misma sucursal nombrada en el servidor
  •   
  • Cuando necesite comentarios o ayuda, o si cree que la sucursal está lista para fusionarse, abra una solicitud de extracción
  •   
  • Después de que alguien más haya revisado y firmado la función, puedes fusionarla con el maestro
  •   
  • Una vez que se fusiona y se empuja a "maestro", puede y debe implementarlo de inmediato
  •   
    
respondido por el AdrianoFerrari 07.08.2014 - 13:22

Lea otras preguntas en las etiquetas