git para proyectos personales (unipersonales). ¿Exceso?

84

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?

Anto
fuente
61
No, uso git y hg para proyectos personales. Tener control de revisión local es un regalo del cielo.
wkl
77
Git es en muchos aspectos mejor para todos los proyectos, ya sea que tengan un gran número de contribuyentes o no: git comprime cosas mucho, mucho más eficientemente que svn (¡y es un orden de magnitudes más rápido!), Git hace que las copias de seguridad sean triviales, y git no lo hará ser un obstáculo si alguien más quiere contribuir.
Artefact2
44
Yo uso el control de versiones para empujar mi código para cualquiera github o bitbucket, TI como servidores de reserva para mí, y tal vez algún día voy a escribir algo realmente la gente va a estar realmente interesado en.
Mahmoud Hossam
8
"No necesito la capacidad de hacer mi propia rama, la rama principal es mi rama". Mucha gente dijo lo mismo sobre undocuándo era una característica relativamente nueva en las aplicaciones. Ahora todos se dan cuenta de que lo necesitaban todo el tiempo. Necesitas ramificarte, simplemente no lo sabes.
Dan Rosenstark
1
@rtperson, sí, puedes hacerlo, pero en realidad me gusta más mercurial, aunque me gusta más github que bitbucket.
Mahmoud Hossam

Respuestas:

155

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!

Spoike
fuente
24
Aceptado. No podría haber demostrado ser más equivocado acerca de que git es excesivo que esto;)
Anto
77
Steve341: Normalmente mantengo todos los proyectos de código fuente en una carpeta llamada "proyectos". Ahí es donde guardo todos los repositorios, uno para cada proyecto de código fuente. Nunca tuve la necesidad de realizar un seguimiento de varios proyectos juntos en un mismo repositorio VCS; para eso están los sistemas de gestión de dependencias como Ivy o Maven.
Spoike
3
@ Steve341 ¿Cómo es difícil hacer un seguimiento de estas cosas? Solo tiene una carpeta que contiene todos sus repositorios. No es diferente a su sistema, aparte del hecho de que su sistema es una práctica extremadamente mala cuando usa git ...
alternativa
2
@ Steve314:echo 'for dir in projects/*; do cd "$dir"; git push; cd ..; done' > update_all; chmod +x update_all
André Paramés
2
git inity bam! Ah, sí, y luego cp ../the-other-project/.gitignore .antes de la confirmación inicial. Bam!
Dan Rosenstark
46

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.

Greyfade
fuente
Supongo que debería haber usado "poderoso" en lugar de "complejo"
Anto
3
@Anto: no importa. Todavía diría básicamente lo mismo: la ramificación superior de Git simplemente no tiene inconvenientes, en comparación con SVN.
greyfade
3
Git tampoco "contaminará" su árbol fuente con archivos de seguimiento en cada subdirectorio.
WarrenT
44
@WarrenT el árbol de origen "contaminación" no ocurre en svn versiones 1.7 y posteriores.
favor el
44
Crear un repositorio del sistema de archivos en Subversion es un comando ( svnadmin createmás uno para realizar el pago inicial o importar), no es necesario configurar permisos, etc. No niego que Git es a menudo una mejor herramienta, pero las imprecisiones sobre Subversion no son útiles.
Josh Kelley
34

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.

Berin Loritsch
fuente
2
Sí, creo que este es el punto de las ramas, la experimentación. Esa fue mi primera reserva cuando leí la pregunta de Op. Si no se está bifurcando en su repositorio, se está "bifurcando" en su cabeza y esto simplemente no tiene sentido cuando tiene el control de versiones en su lugar.
Chris
3
Puedes ramificarte con subversión. Y fusionarse. Algo así como. En realidad, la única vez que lo intenté terminé con un repositorio corrupto con el que ya no podía trabajar, y recuperarme de una copia de seguridad (con la rama ya aplicada) no ayudó, así que terminé perdiendo todo mi historial y comenzando un nuevo repositorio ... pero culpé de eso a la transición de 1.4. a 1.5 (creo que fue hace unos años). Probablemente la ramificación y la fusión funcionan, de verdad. Si eres lo suficientemente valiente como para probarlo. Si hubiera sabido sobre svn dump en ese entonces, podría haber solucionado el problema con cierto esfuerzo, por supuesto.
Steve314
@ Chris, me gusta tener una versión funcional a la que pueda recurrir en cualquier momento. Claro que puedes lograr eso con etiquetas, pero hay momentos en que una rama tiene mucho sentido. No olvide los otros beneficios de git / mercurial tampoco.
Berin Loritsch
9

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?

metal de piedra
fuente
Podría ser excesivo (sí, con esa definición) si el sistema se interpuso en su camino. Me pregunto si es una buena idea usar git para proyectos personales. ¿Podría decirme cuáles son las ventajas específicas ? Esta respuesta no aborda eso. Veo a git como un sistema más poderoso y demasiado poderoso para proyectos personales. Sin embargo, no necesariamente debe haber ningún daño, siempre y cuando no se interponga en tu camino. ¿Podrías ampliar tu respuesta?
Anto
1
Overkill también se usa cuando el esfuerzo utilizado para aplicar la solución está fuera de proporción. Podría decirse que si ya está utilizando Subversion para proyectos locales, el esfuerzo necesario para aprender Git o lo que sea es excesivo. O posiblemente una lección útil para desarrollar habilidades transferibles, por supuesto. Personalmente, sigo usando la subversión: me ha mordido algunas veces, pero solo dejó cicatrices menores. Estoy interesado en aprender Git, pero cada vez que busqué, los tutoriales que encontré eran crípticos o no podía obtener herramientas estables para Windows o había algún otro obstáculo que hacía que todo pareciera, bueno, excesivo.
Steve314
7

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.

dsimcha
fuente
7

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.
Karl Bielefeldt
fuente
6

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".


fuente
2

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.

Chris Moschini
fuente
1
Sí, uso DropBox para proyectos personales. El control de versiones es ni de lejos tan sofisticado como un verdadero VCS pero está bien para proyectos más pequeños que hago en mi tiempo libre, y no requiere ninguna atención en absoluto (por ejemplo, no se compromete, archivos simplemente actualizar a medida que trabaja en ellos..)
jhocking
Ah, y de paso porque desarrollo juegos, mis proyectos tienden a tener muchos archivos binarios (archivos de imagen, clips de audio, etc.) y la mayoría de los sistemas de control de versiones solo están destinados al código fuente.
jhocking
Git funciona bien con archivos binarios, las diferencias son menos interesantes. Afortunadamente, diferenciar en git no está exactamente bloqueado: si puede encontrar una herramienta de diferencia binaria que le guste, puede usarla con git con bastante facilidad (desde la línea de comando)
Chris Moschini
Me dijeron que Git desperdicia mucho espacio versionando archivos binarios, pero lo que me dijeron puede ser incorrecto. Básicamente, me dijeron que la mayoría de los recursos binarios (supongo que no todos los archivos binarios, pero las imágenes y los sonidos que se incluyen en un juego) deben guardarse en su totalidad en cada versión, por lo que Git llena su disco duro con el repositorio local.
jhocking
Solo es un desperdicio si no quisiste versionar los archivos binarios. Si necesita versionarlos, entonces el historial de versiones no es un desperdicio. Creo que están implicando accidentalmente que git hincha su historial de versiones al rastrear binarios, eso es incorrecto. git.wiki.kernel.org/index.php/GitSvnComparsion
Chris Moschini
2

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.

perdian
fuente
1

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!

Wlangstroth
fuente
1
Eso suena un poco relacionado con lo bien que sabes darcs. Nunca lo he usado, pero he usado mucho git. Para mí, git es muy sencillo, pero apuesto a que me estaría rascando la cabeza si tuviera que usar darcs.
Sam
1
Si ya has dominado la loca interfaz de usuario de git, darcs sería un juego de niños.
wlangstroth
1
¿puede, por favor, explicar por qué darcs es mejor para proyectos pequeños que git?
shabunc
0

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.

WarrenT
fuente
Para las opiniones del diseñador sobre esto, mire a Linus en Git en YouTube (~ 70 minutos)
WarrenT