Estoy usando SVN en este momento, y he usado CVS y VSS en el pasado. SVN es el favorito actual en mis libros, pero he estado oyendo mucho sobre git. De las personas que han usado git, ¿cuáles son los pros y los contras de su experiencia?¿Cuáles son tus pros y contras de git después de haberlo usado?
no tengo mucho de experiencia con Git, pero:
Pros:
(. En realidad no he "necesario" el lado distribuida de cosas, sin embargo, más allá de ser capaz de tener un repositorio local y empujar a uno público)
Contras:
git add) tomó un tiempo para captarEn cuanto a libros, hay este libro Beta de los programadores pragmáticos: http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git – Abizern
No hay problema con el uso de Git desde el símbolo del sistema de Windows, De Verdad. He estado usando msys Git de Powershell y cmd.exe sin problemas desde hace un tiempo. En cuanto a la falta de integración de Explorer, eso es un profesional para mí :-))). –
Ooh ... No me di cuenta de que git está bien desde un cmd.exe normal. Debe intentarlo ... –
Gran pregunta, he estado usando SVN durante bastante tiempo, y me siento muy cómodo con ella. Pero tuve que usar Git un par de veces para obtener el código fuente de diferentes proyectos de código abierto. Todavía no me he tomado el tiempo para realmente aprender sobre eso. ¿Vale la pena?
También me pregunto cuáles son las ventajas de usar el control de versión distribuida sobre un VCS normal como subversión.
Skeet tiene la mayoría de ellos, pero:
Pro:
Siempre me pareció bastante fácil en svn (y lo usé mucho), pero todavía no lo he probado en git. –
La ramificación no es mucho más fácil que SVN, pero la fusión en git es trivial. Esa es una gran diferencia. –
La fusión es mucho más simple en Git desde la creación de ramas es el valor por defecto, no es una opción adicional. Entonces, cuando tienes que fusionar algo, simplemente lo comprometes y luego unes las dos ramas (la existente y la nueva que git creó automáticamente para tu última comprobación).
Además, cuando usas git, siempre tienes todo el repositorio contigo. Puede registrarse mientras está fuera de línea y fusionarse más tarde (ya que la fusión es mucho más simple).
El inconveniente es que GIT es casi inutilizable en una unidad USB en Windows.Windows desactiva el almacenamiento en caché de estos y GIT funciona con millones de archivos pequeños. Además, todavía falta soporte de IDE. No estoy seguro de que esto último sea realmente un problema. La interfaz de usuario que viene con GIT es bastante agradable.
Además, no estoy 100% contento de que tenga que "agregar" archivos existentes todo el tiempo [EDIT] y la enorme cantidad de características. Para un principiante, son abrumadores y a menudo no está claro por qué querría utilizar una determinada opción/comando. Quiero decir, CVS viene con, digamos, 20 comandos. GIT viene con 73 y cada uno tiene muchas opciones (y eso sin contar los comandos de plomería ...).
Git commit -a combinado con un .gitignore decente funciona en torno al problema de agregar archivos existentes. –
El soporte de Windows es pésimo, así que me moví al Mercurial, otro DVCS que es tan bueno.
Las ventajas de DVCS se hacen aparentes cuando, por ejemplo, tiene un repositorio en su servidor en la oficina y está trabajando en el sitio. Ser capaz de comprometerse localmente sin acceso a la oficina de su servidor (y esta reversión cuando sea necesario) es brillante.
Mucha gente lo negaría, pero la elección de la herramienta de gestión de código fuente influye en la forma en que trabaja. Solía trabajar mucho con Subversion, hasta que descubrí a Git por mí. Evité principalmente la ramificación en Subversion. Cuando no podía evitarlo, prefería configurar un espejo local (usando svk). Mientras que la bifurcación se realiza fácilmente tanto en Subversion como en Git, solo Git hace que la fusión (¡y el rebase!) Sea divertido, Subversion siempre ha sido un dolor real a la hora de fusionarse.
Lo segundo que realmente me gusta de Git (aparte de todos los puntos que ya se han mencionado) es el "índice", un área de preparación que contiene su próxima confirmación, y la posibilidad de agregar solo fragmentos de una modificación archivarlo.
La última versión de Git puede funcionar directamente en el símbolo del sistema de Windows, que es cómo la uso. El proceso es bastante trivial para mí ahora.
También tengo instalado Git en un disco duro externo y en mi jumpdrive. Cuando en una computadora nueva, ejecuto un script que establece temporalmente la ruta para incluir las herramientas de Git. ¡Entonces puedes continuar desarrollando!
Pro:
Contras:
Me gustó git-gui y qgit –
No puede verificar una parte del repos porque es un concepto de control de revisión distribuido, que como usuario debe tener un repositorio completo en su máquina local. Tenga en cuenta que solo una vez cuando clona proyecto en la máquina local, extrae todo. La próxima extracción le dará solo cambios. –
Trabajar con git es muy diferente de lo que es trabajar con otros sistemas de control de versiones.
Tener un repositorio local es muy importante. Significa que puede usar toda la potencia del sistema de control de versiones (y esto es mucho con git) sin molestar a nadie. Si hay un problema controvertido en su proyecto, puede trabajar en él de forma privada, creando ramas, apilando parches y puliéndolos. De esa forma, puede regresar con un parche planchado. Pero incluso en "funcionamiento normal" es mucho mejor si puede limpiar sus parches antes de mostrarlos al público y, de hecho, la eliminación de errores es mucho más fácil si tiene parches sanos y no solo instantáneas de "fin de día".
Antes de comprometer un conjunto más grande de parches, normalmente reordenar los parches y comprimir las correcciones de errores en mi nuevo código directamente en el parche. Entonces los parches parecen no haber cometido ningún error. Después de eso, mi rama privada se actualiza en HEAD y luego se presiona. Por lo general, nunca utilizo una combinación, ya que solo complica la historia.
En resumen: permite mantener su historial limpio.
Esto le da una visión muy diferente de su trabajo. Le permite ver el estado actual como una adición de parches individuales que crean un historial que no es solo un registro, sino algo que usted pone allí a propósito. Los conjuntos de parches son los ladrillos de los que construye su aplicación, y se mueven al lugar correcto si es necesario.
Nunca volvería voluntariamente a ningún otro sistema de control de versiones que haya usado antes de git o de cualquier sistema de control de versiones que no sea compatible con rebase, ramas locales y commits.
Otras consideraciones:
Pros:
Contras:
número de comandos
Mientras SVN y otros modernos como VCS Hg o otros son buenas herramientas y útiles git es una tienda llena de máquinas-herramienta. Esto cuenta como pro y como estafa al mismo tiempo. Mientras que svn tiene 30 comandos (según 'svn help'), git envía 130 páginas de manual con más o menos cada una de ellas describiendo un solo comando. Una razón para esto es que git expone las funciones de nivel más bajo que la mayoría de los usuarios necesitarán como herramientas de línea de comandos. Pero incluso sin esos comandos de bajo nivel, git envía muchas herramientas muy potentes y no se encuentran en ningún otro VCS que conozco (ver git-bisect, git-filter-branch, git-cherry o git-reset para ver ejemplos).Si bien es muy útil tener esas herramientas a mano, es bastante difícil para los principiantes entender qué comando necesitan y necesitan saber y cuáles no.
Modelo de Desarrollo
Un tema es que git es lo suficientemente potente como para soportar diferentes modos de funcionamiento. Esto hace que sea difícil para los principiantes ya que no hay realmente un documento de "mejores prácticas" ya que la mejor práctica no es construir en git. Por lo que tiene que decidir sí mismo si
Como usted tiene su repositorio local, puede incluso utilizar una un modo de operación muy diferente al proyecto en el que está trabajando y simplemente ajuste sus conjuntos de cambios antes de empujarlos/publicarlos.
Camino de los cambios
Otra cosa que también cuenta como favor y en contra dependiendo de su punto de vista es que el trabajo con Git es más complicado que con cualquier VCS centralizados e incluso más complicado mayoría de los demás VCS distribuido.
Con VCS centralizado, normalmente solo hace una confirmación y los cambios que realiza van al repositorio. En git, los cambios pueden pasar por un número bastante grande de pasos antes de que terminen en su destino final. Los pasos típicos son (medidas no tan comunes entre paréntesis):
Como puede omitir el índice, hay por lo menos 2 pasos involucrados, pero por lo general hay más. Esto requiere una comprensión más profunda de lo que estás haciendo y escribir muchos más comandos. Por otro lado, esto le da control sobre cada uno de estos pasos.Puede
Todo este poder y las decisiones hacen que sea difícil para los principiantes comenzar con git. Una vez que se dominan, dan un enorme control sobre el código.
acceso de escritura
One Pro importante para cualquier VCS distribuido es que los contribuyentes no requieren acceso de escritura a beneficiarse de la VCS. Todos los que tienen acceso de lectura pueden simplemente clonar el repositorio, crear ramas cuando sea necesario y comenzar a apilar conjuntos de parches puestos. Trabajar con cvs sin acceso de escritura es un verdadero dolor, con git no hay una gran diferencia en cómo obtener sus parches. Esto no es solo una ventaja técnica sino que también ahorra discusiones complicadas sobre si este noobie realmente debería tener acceso de escritura.
Al menos algunos de los comandos enumerados no son únicos. Mercurial tiene el comando bisect (http://hgbook.red-bean.com/hgbookch9.html#x13-1880009.5), Subversion tiene svndumpfilter. – Constantin
Pros: Why Git is Better Than X
Pros:
Contras:
extraño comportamiento de autocrlf en Windows
imposibilidad de mover/cambiar el nombre de archivo o insode dir repo y kepp su comprometan la historia (git mv sólo elimina el archivo de cesión temporal, renombra y lo añade a repo de nuevo, perdiendo así toda la historia)
Eso o no está bien, o es obsoleto. Git detecta movimientos, ya sea que los hagas con 'git mv' o fuera de git y los controles, en función de las similitudes de archivos. Es posible mover Y hacer suficientes cambios en una confirmación que no detecta esto, pero en algún momento, eso hace que el hecho de que comenzó con un archivo en particular sea algo irrelevante de todos modos. Un flujo de trabajo cuando se trata de movimientos es ocultar las ediciones, rehacer el movimiento y registrarlo, y luego volver a aplicar las ediciones almacenadas. –
Este es una buena pregunta, lástima que esté cerrada. Una de las desventajas reales de git aquí es que es más difícil de usar cuando necesitas buscar un repositorio muy grande con un gran historial de confirmaciones, solo para ver el origen o hacer un parche simple. En svn, obtiene directamente las fuentes del último cabezal y puede reanudar la descarga si falla la conexión. En git incluso con '--depth 1' obtienes una gran sobrecarga de otras cosas y si estás en una conexión inestable y lenta, puede ser incluso imposible de obtener – Petr
Me gusta git en su mayor parte, pero los profesionales están cubiertos por lo Mencionaré con. Con eso, para un novato, en realidad es muy fácil perder los cambios. Cuando comencé, frecuentemente obtenía un estado de cabeza separada y cuando cambiaba a otra revisión/rama, perdía mis compromisos. – Chance