git para proyectos personales (unipersonales). ¿Exceso?

Sé y uso dos sistemas de control de versiones: Subversion y git. Subversion, a partir de ahora, se utiliza para proyectos personales donde soy el único desarrollador y git se utiliza para proyectos de código abierto y proyectos donde creo que otros también trabajarán en el proyecto. Esto se debe principalmente a las increíbles capacidades de bifurcación y fusión de git, donde todos pueden trabajar en su propia sucursal; muy útil.

Ahora, uso Subversion para proyectos personales, ya que creo que git tiene poco sentido allí. Parece ser un poco exagerado. Está bien para mí si está centralizado (en mi servidor doméstico, generalmente) cuando soy el único desarrollador; Tomo copias de seguridad regulares de todos modos. No necesito la capacidad de hacer mi propia rama, la rama principal es mi rama. Sí, SVN tiene un soporte simple para la ramificación, pero creo que no tiene sentido un soporte mucho más poderoso para ello. La fusión puede ser un dolor con ella, o al menos desde mi poca experiencia.

¿Hay alguna buena razón para que use git en proyectos personales, o es simplemente una exageración?

No es exagerado. La razón principal por la que comencé a usar Git y Mercurial sobre Subversion para proyectos personales es que iniciar un repositorio es mucho más fácil.

¿Quieres comenzar un nuevo proyecto?

> git init

BAM! No es necesario configurar un servidor de repositorio ni registrar una estructura de carpetas para admitir la ramificación y las etiquetas en un repositorio de subversión.

Compartir su proyecto más tarde es solo una cuestión de: git push(además de tener un repositorio remoto). ¡Intenta hacerlo rápidamente con subversion!

Yo diría que usar Subversion para proyectos personales locales es excesivo, mientras que Git definitivamente no lo es. Git ocupará menos espacio (debido al concepto ineficiente de "revisiones" de SVN frente a las instantáneas de objetos de Git), requiere menos configuración ( git initfrente a una docena de svnadmincomandos y permisos de configuración, etc.), es más fácil hacer una copia de seguridad ( git clone --bare[o git push originsi usa Github o similar] y ya está), y tiene mejores herramientas para administrar su código (la ramificación es gratuita y la fusión es más fácil y limpia). El hecho de que nadie más tenga un clon de su repositorio no significa que los beneficios de cualquier DVCS sean "excesivos".

Además, diría que el soporte de ramificación de Git es menos complejo que el de SVN, con mayores recompensas.

Pensar que nunca ramificará su propio código es un poco miope. He ramificado mi propio código varias veces, especialmente cuando estaba experimentando con un nuevo enfoque del que aún no estaba completamente convencido. Eventualmente querrás la función.

Esto viene de un usuario de Subversion desde hace mucho tiempo. Consolidar en una herramienta realmente puede ayudar a facilitarle la vida.

Overkill está reservado para cuando hay un daño colateral causado por la "solución". El uso de una pistola para matar una mosca significa que la bala va a ir a otro lado. Es exagerado. Usar algo más poderoso de lo necesario que no causa un problema no es excesivo y puede ser algo bueno si te ayuda a optimizar tu proceso de desarrollo. No causa ningún daño y le permite tener que actualizar solo un conjunto de software en lugar de dos. Entonces, ¿por qué molestarse con dos sistemas en lugar de uno?

Uso Git para mis proyectos individuales y me encanta. Anteriormente estaba usando Subversion y aún no he visto una desventaja de usar Git. Es más poderoso pero no de una manera que haga las cosas simples más complicadas. Hacer cosas simples innecesariamente complicadas / caras / lentas / etc. En mi humilde opinión es una condición necesaria para llamar a algo exagerado. Además, en Github, bifurqué los proyectos individuales de otras personas para agregar una función que quería y luego les envié solicitudes de extracción. Me parecería genial si alguien interesado en mis proyectos hiciera lo mismo.

Yo no utilicé control de origen en proyectos personales antes DVCS, así que es un poco raro imaginar que alguien tome el punto de vista opuesto. Algunas de mis razones son:

• Fácil de instalar y desmontar. Por ejemplo, un colega me dio un rompecabezas de programación la semana pasada que resolví en varios pasos pequeños. Hice un repositorio de git que duró 45 minutos para mantener mi trabajo, y luego desapareció. No sé lo fácil que es algo así en Subversion, pero nunca he oído que alguien lo haga.
• Desconectado. Para mí, poder trabajar sin conexión es mucho más beneficioso para un proyecto de pasatiempo que uno para el trabajo. No necesito hacer un agujero en el firewall de mi casa ni organizar un proyecto públicamente. Puedo poner temporalmente un repositorio en una memoria USB o una computadora portátil, y aún así mantener todo sincronizado.
• Todo colocado. Tener el repositorio y el árbol de trabajo juntos hace que los proyectos pequeños sean más fáciles de rastrear durante cosas como las actualizaciones del sistema operativo.
• Potentes funciones. Claro, no necesito el poder todo el tiempo, pero está ahí cuando lo necesito y no consume ningún recurso cuando no lo necesito.

Me han dicho que git-bisectes realmente bueno para encontrar el commit exacto que introdujo un comportamiento dado, navegando de un lado a otro en commits dependiendo de su entrada.

Usted va a tener que hacer eso algún día por cosas que simplemente no puede averiguar lo que ha sucedido.

EDITAR: Además, la capacidad de bifurcar es muy importante cuando tienes que hacer correcciones de errores en versiones antiguas que usan los clientes. Debe ser capaz de administrar "solo arregle esta pequeña cosa, pero no quiero la versión más nueva porque no quiero probarla de nuevo ahora".

Depende de la seriedad que desee obtener sobre el control de versiones de su propio código. Si lo que está creando es, por ejemplo, una biblioteca simple que solo tendrá la versión actual (o mientras sea cierto), personalmente solo usaría una opción de copia de seguridad básica como Dropbox. Si pierde todo su código, puede recuperarlo de la web, y Dropbox tiene una copia de seguridad de la versión de 30 días si realmente hace algo estúpido.

Sin embargo, si, por ejemplo, necesita mantener las ramas de producción y desarrollo, entonces git es absolutamente una gran herramienta, y mucho más rápido que svn. Sin embargo, tenga en cuenta el riesgo de falla del disco duro si solo almacena los datos localmente.

Siempre, siempre, siempre uso un sistema de control de versiones para cualquier tipo de proyecto de desarrollo. Grande o pequeño realmente no importa. Ya sea que esté jugando en casa con algún tipo de tecnología nueva, escribiendo un pequeño ayudante para facilitar mi vida o desarrollándome profesionalmente en un equipo grande y distribuido, siempre quisiera un sistema de control de versiones que me respalde.

Claro, la mayoría de las veces para pequeños proyectos personales no utilizará la mayoría de las funciones, pero configurar un repositorio git (o incluso un repositorio local de Subversion) no es gran cosa, ¡así que anímate! Y antes de que te des cuenta querrás saber "maldición, ¿cuál era el contenido del archivo X el viernes pasado?". Sin control de versiones: buena suerte ;-)

Entonces, realmente no importa si usa git o SVN, personalmente estoy empezando a migrar más y más cosas de SVN a git, pero lo principal es usar el control de versiones, incluso para las pequeñas cosas.

Solo porque nadie lo ha mencionado: para proyectos personales, darcs es realmente bueno y menos involucrado que git para hacer un control de versiones sencillo. ¡No es tan rápido para proyectos más grandes, pero tampoco lo es Subversion!

Puede ser un poderoso cambio de paradigma mental comprender que lo que hacemos es experimentar. Tener una herramienta barata / fácil para respaldar esto, mejora su capacidad de avanzar, en parte porque mejora su capacidad de retirarse de cualquier experimento cuando resulta mal.

Muchos desarrolladores dicen: Bueno, solo hago copias de mi código. Pero estas copias se vuelven difíciles de manejar y terminan en desorden. Tiene varias copias y no puede recordar qué copia para qué, y luego trate de averiguar cuándo es seguro eliminarlas.

Todo esto se vuelve aún más valioso cuando el experimento implica cambios coordinados en múltiples archivos. Y cuando se trata de un proyecto en solitario, usar Git se vuelve aún más simple.

En lugar de preguntarme si debería usarlo en un proyecto en solitario, ahora creo que es una pena no haber descubierto esto antes.