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

60

Tengo múltiples proyectos en Git en los que eventualmente quiero atraer a otros. Sin embargo, en este momento solo soy yo y uso Git y GitHub de manera muy simple: no hay ramas y, básicamente, solo uso los commits como copia de seguridad de mis archivos locales. A veces vuelvo y veo las versiones anteriores de mis archivos como referencia, pero no he necesitado hacer retrocesos hasta este punto, aunque aprecio la opción si la necesito en el futuro.

Como desarrollador exclusivo, ¿qué características de Git o GitHub podría aprovechar para beneficiarme en este momento? ¿Cómo debería ser mi flujo de trabajo?

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

VirtuosiMedia
fuente
3
Como otros han explicado, Git te da mucho poder. Sin embargo, como desarrollador exclusivo, lo más importante que apreciará más adelante es que si le proporciona un registro de los cambios que realizó (agrupando los cambios en varios archivos en un conjunto), cuándo los realizó y por qué. También es una buena práctica para cuando te conviertes en parte de un equipo.
Leading Geek
1
Cerrado porque interesante. :)
@ user93458 como siempre! Los temas cerrados suelen ser exactamente lo que estoy buscando.
Miroslav Popov
Excelente pregunta que nunca debería haberse cerrado.
volumen uno

Respuestas:

64

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

Por supuesto. Hay 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 publicadas o cambios importantes. Esto puede ser adoptado fácilmente por los nuevos desarrolladores que se unen a su proyecto.

Además, la ramificación es útil incluso si está trabajando solo. Por ejemplo, encuentra un error mientras codifica una nueva característica. Si no usa ramas, deberá 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 característica, puede simplemente retirar la rama de desarrollo, corregir el error y volver a pagar la nueva rama de característica.

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

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

Cristian
fuente
+1 - Eso tiene sentido. Echaré un vistazo más de cerca a ese artículo también, parece muy útil.
VirtuosiMedia
No soy un especialista en git, principalmente un usuario de Mercurial. ¿Este consejo de la rama de desarrollo sigue siendo válido en el caso de Mercurial? Parece que sí, pero tal vez algunas diferencias hacen que no sea una buena idea en este caso.
Klaim
2
Sí, es válido para todo el control de fuente. De hecho, lo hago al revés con SVN; el tronco "principal" es para el último desarrollo, que se realiza a diario o incluso con más frecuencia. Cuando se solicita una versión, el código se congela y se corta una rama. Esa rama solo recibe actualizaciones menores para solucionar problemas importantes de lanzamiento, y luego se crea el distribuible a partir de eso. De esa manera, tengo una rama del código fuente detrás de cada versión lanzada. Esto es mejor que simplemente etiquetar o etiquetar b / c si los commits llegan después de la etiqueta pero antes del lanzamiento, no se sabe si realmente se excluyeron.
KeithS
+1 para el artículo; @Klaim - sí, funciona muy bien para hg también. realmente debería llamarse "modelo de ramificación DCVS exitoso"
Wyatt Barnett
+1 gracias por el enlace, cambió la forma en que trabajaré con git, no por mucho que piensen, pero como dicen, ¡cada poquito ayuda!
Newtopian
14

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 la manera git, así que hice un poco de exploración. luego volvió al flujo de trabajo que describió.

Después de un tiempo, esto se volvió difícil de trabajar ya que surgieron algunas situaciones y también me dio malos hábitos que serían difíciles de romper una vez que me uniera a un equipo.

así que me decidí por lo siguiente:

  • Depósito local para trabajar.
  • Rama maestra como troncal estable para la aplicación
  • Una rama para cada función / refactor, básicamente una rama para cada cambio considerable que se realizará.
  • Vuelva a fusionar al tronco cuando la rama esté estable y pasen todas las pruebas.

También configuré una cuenta git hub donde sincronizo el enlace 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 tengo la costumbre de 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 lo lanzo al cliente, saldré de esta versión para crear un segundo tronco 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 empiezo a correr círculos me di por vencida y comencé otra rama para trabajar en otra cosa. 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 rápidamente e ideas 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 dado que estoy solo, dudo que realmente necesite hacerlo. Empujó como "agradable de aprender".

Cuando toda la ramificación se volvió complicada, exploré la opción de registro para dibujar un árbol de cambios y ver en qué rama estaban.

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

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

Un último consejo, la línea de comando es tu amigo. No quiere decir que las herramientas gráficas no sean buenas, sino todo lo contrario, pero realmente me sentí mal cuando bajé a la línea de comando y lo probé. 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 consola fea 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. Y la línea de comandos para bifurcar, fusionar, empujar, obtener y los árboles de registro más complejos . algunas secuencias de comandos básicas y nunca he sido tan productivo con respecto al control de fuente y nunca tuve tanto control sobre mi fuente.

Buena suerte, espero que esto ayude.

Newtopian
fuente
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. Al trabajar 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 ramificación, pero no tiene sentido complicar las cosas hasta que lo necesite.

Karl Bielefeldt
fuente
4

Para un modelo más simple, puede ver lo que hace GitHub. El "flujo de GitHub" es muy simple, y hay una excelente guía aquí: https://guides.github.com/introduction/flow/index.html

Resumen ( del blog de Scott Chacon ):

Entonces, ¿qué es GitHub Flow?

  • Cualquier cosa en la rama maestra es desplegable
  • Para trabajar en algo nuevo, cree una ramificación con nombre descriptivo fuera del maestro (es decir: new-oauth2-scopes)
  • Comprométase con esa rama localmente y empuje regularmente su trabajo a la misma rama 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 otra persona haya revisado y firmado la función, puede fusionarla en master
  • Una vez que se fusiona y se empuja a 'maestro', puede y debe implementar de inmediato
AdrianoFerrari
fuente