Trabajo en un departamento donde nadie ha usado el control de fuente antes, incluido yo mismo.

Estoy tratando de impulsar el concepto. He pasado un tiempo investigando SVN. Aprendí algunos conceptos básicos. Puedo Crear / actualizar / finalizar / confirmar con la línea de comando y desde Tortoise. Estoy empezando a aprender a etiquetar y ramificar, pero aún confundo mucho sobre los conflictos entre ramas y troncos, etc. Todavía estoy aprendiendo, pero no tengo una persona física que pueda mostrarme nada. Todo es de libros / tutoriales y prueba y error.

Por lo que he leído en línea, parece que gites mejor saberlo, pero también es más complicado. No quiero abrumarme. ¿Debo seguir dominando svn antes de pasar a git o sería más inteligente saltar a git ahora?

¿Hay ventajas y desventajas de ambos enfoques?

No

Git es tan radicalmente diferente de SVN que no te ayudará. En todo caso, buscará comandos de "actualización" y "confirmación" y se preguntará por qué todo es diferente.

Comience con Git desde abajo hacia arriba y vaya desde allí.

Contrastar un sistema de control de versiones de actualización / confirmación centralizado estándar con Git es como comparar un autobús con el transporte público. Un autobús lo llevará a usted (y a todos los demás) del punto A al punto B utilizando exactamente la misma ruta. El transporte público lo llevará del punto A al punto B utilizando la ruta que desee.

Distribuido en sí tiene desventajas que debe tener en cuenta. Se necesita más trabajo para mantener a todos en la misma página. Sin embargo, ofrece un gran aumento de flexibilidad.

Revisión de hashes vs. Números

Alguien mencionó a Git usando hash SHA1 mientras que Hg usa números.

Primero, rara vez (si alguna vez) necesita lidiar directamente con los hashes en los commits / pulls diarios. Debe extraer el registro y extraer hashes si está haciendo diffs o algunos de los elementos de rebase más difíciles.

Con Git, todos tienen los mismos hashes. Los repositorios diferentes no tienen números de confirmación diferentes y todos están en la misma página. Con Hg esto es menos. En la práctica, si tiene que extraer los hash de confirmación y trabajar con ellos (ya sea para comparar o recorrer la línea de tiempo del código), es más fácil sincronizarse con otras personas cuando tiene hashes en lugar de números.

No, por favor, ni siquiera te molestes.

En serio, comience desde un DVCS. El hecho de que SVN sea popular no lo convierte en el estándar. Linus Torvalds te diría que podría pudrir tu cerebro .

Lea este gran artículo / introducción de Joel Spolsky llamado Subversion Re-education .

También podría estar interesado en leer esta otra pregunta: soy un geek de Subversion, ¿por qué debería considerar o no Mercurial o Git o cualquier otro DVCS?

Elegir entre DVCS

Personalmente, uso tanto mercurial como git, y creo que es importante conocer ambos. Una lectura recomendada sobre esto es Git vs. Mercurial: Relájese (vea el ejemplo de git-addremove). Dos citas de ese artículo que creo que lo resumen.

En cuanto a git:

La filosofía de diseño de Git es inequívocamente la de Unix: a diferencia de Subversion, CVS o Mercurial, git no es un binario monolítico sino una multitud de herramientas individuales, que van desde comandos de "porcelana" de alto nivel como git-pull, git-merge y git-checkout a comandos de "plomería" de bajo nivel como git-apply, git-hash-object y git-merge-file. Entonces, al igual que MacGyver, puedes hacer casi cualquier cosa que necesites con Git: esto incluye motores Wiki totalmente impresionantes, rastreadores de problemas, sistemas de archivos, herramientas de administrador de sistemas, todo menos la reparación de fusibles.

En cuanto a mercurial:

Los desarrolladores a quienes les gusta mantener limpio su sistema probablemente apreciarán el hecho de que hg instala un binario en contraste con los 144 que componen git, y los desarrolladores que piensan que la capacidad de git para editar sus confirmaciones anteriores es tonta, innecesaria y peligrosa, apreciarán el simplicidad hg proporciona al omitir esa característica particular.

Se pueden encontrar muchos proyectos en github y git es más poderoso, pero también puede ser algo intimidante para los recién llegados, especialmente los usuarios de Windows. También hay bitbucket (equivalente de github para mercurial).

Mi recomendación: comienza con mercurial y tan pronto como te sientas cómodo con él, elige git; no se trata de las herramientas, se trata de las personas con las que trabaja .

Lo que considero que el uso real y práctico de Subversion es, no para trabajar con otras personas, sino para quizás implementar un actualizador para sus aplicaciones de producción, esta es la razón:

• Actualmente, svn está casi instalado en la mayoría de los proveedores de hosting
• Tiene un buen soporte para subproyectos (ahora direccionable en git y hg). svn upy su proyecto y sus dependencias se actualizan.

Citando a Thorbjørn en este otro hilo :

Los DVCS son para Subversion, lo que Bittorrent es para ftp

Editar : si hay un VCS que debe conocer antes de Git, podría ser Mercurial (una interfaz CLI mucho más amigable y buena para introducirse en los conceptos distribuidos). Este consejo se aplica especialmente a aquellos que provienen de Subversion ya que la CLI también es similar en algún grado. El Control de versiones distribuido puede ser más fácil de aprender que el Control de versiones centralizado, ya que solo le preocupa su instancia de repositorio y no las partes del cliente y del servidor por separado .

Deberías aprender lo que piensas usar. Git es popular, al igual que Mercurial también disfrutó de cierta popularidad. Git / Mercurial son sistemas de control de fuente distribuida.

Lo más importante al presentar un nuevo concepto a un equipo (y es lamentable que el control de versiones se considere un tema nuevo para demasiados equipos), ayuda a delinear sus objetivos y criterios de evaluación. No tiene que ser súper formal al respecto, pero hágase las siguientes preguntas:

• ¿Cuál es el propósito del control de versiones en nuestro equipo? Sí, todos los sistemas de control de versiones que valen la pena le permitirán volver al historial y ver qué ha cambiado en un archivo determinado. Sin embargo, ¿lo va a utilizar para establecer nuevos lanzamientos? (asiente con la cabeza, quieres esto). Esta es la declaración de visión de 2-3 líneas para lo que desea lograr.
• ¿Su equipo está acostumbrado a tener su propio entorno de trabajo local solo para fusionar las cosas con cuidado más adelante? Si es así, la ruta DVCS podría tener más sentido.
• Por el contrario, ¿su equipo está acostumbrado a trabajar desde una unidad compartida y todo está en constante integración? Si es así, el VCS más tradicional podría tener más sentido.

Al evaluar sus alternativas, debe considerar las cosas importantes que todos los VCS deben hacer:

• Código de línea de base (ramas etiquetadas, etiquetas, etc.). Básicamente, ¿cómo se obtiene el código fuente exacto utilizado en una versión de su proyecto?
• Obtenga cambios locales en el servidor central. Debe haber una copia autorizada del código, ya sea que use DVCS o VCS estándar. Cada herramienta trata este proceso de manera diferente.
• Obtenga cambios en el servidor central de su copia local.
• Cómo lidiar con los cambios experimentales. Los VCS le permiten ser más atrevido con los cambios propuestos sin romper el código fuente principal del proyecto. Los sistemas DVCS y VCS estándar abordan esto de manera muy diferente: uno de ellos funcionará mejor para su equipo.
• ¿Cómo se configuran y configuran los servidores?
• ¿Necesitas autenticación? Si es así, ¿cómo se asegura de que solo las personas a las que se les permite hacer cambios realmente puedan hacerlo?

Al final, haga una evaluación rápida para determinar si los sistemas VCS o DVCS estándar serán los mejores para su equipo. Tendrá que elegir la herramienta que proporcione la menor cantidad de dolor o es probable que no sea adoptada. Después de eso, evalúe sus alternativas que mejor se adapten a sus necesidades.

Al final, aprenda lo que piensa usar.

Creo que mucha gente encuentra git más complicado que svn porque es diferente. Después de usar subversion (o cvs, etc.) por un tiempo, puede ser difícil cambiar mentalmente los modos a un modelo DVCS. En base a eso, diría que puede ser de su interés investigar VCS tradicional como la subversión en conjunto con la investigación de un DVCS como git.

Aunque git es mi VCS preferido, diría que probablemente también sea mejor aprender subversión. Por un lado, todavía hay una gran cantidad de repositorios de subversión y cvs con los que puede que tenga que interactuar algún día, y también tendrá una mejor comprensión de las ventajas y desventajas precisas de DVCS sobre VCS tradicional.

Sería contraproducente aprender svn y luego git

Aquí hay algunas razones:

• Gits radicalmente diferente de svn. Git está distribuido y svn es cliente / servidor.
• Diferentes significados están unidos a las mismas palabras. Por ejemplo, 'git checkout ...' tiene un significado diferente de 'svn checkout ...'
• La ramificación es diferente. Git tiene este concepto de ramas 'tema' que son ramas locales baratas que svn no admite.
• Git tiene un lugar adicional, llamado índice, que se encuentra entre el árbol de trabajo y su repositorio. Svn no tiene índice. Usando git, sus cambios se mueven desde su árbol de trabajo al índice y al repositorio.

Mi consejo es aprender git.

En general, hay algunas cosas iguales en GIT y SVN y otras no.

Crear / actualizar / pagar / confirmar

En términos generales, debe recogerlo fácilmente.

cómo etiquetar y ramificar pero aún confundir mucho sobre conflictos entre ramas y troncales, etc.

Diferente entre los dos.

No digo que debas o no debes cambiar ahora (creo que es tu decisión), solo quería señalarlo, ya que es algo a tener en cuenta. Si está seguro de que desea probar Git, puede decidir cambiar ahora para ahorrarse aprendiendo algo en SVN que es diferente en Git.

Guau; 12 respuestas y todos siguen pidiendo la pregunta ...

No, Subversion no es un requisito previo para Git.

No hay un mapeo limpio entre Subversion y Git: si planea aprender ambos, solo tendrá que sufrir el hecho de que usan los mismos términos para diferentes acciones. (Y diferentes términos para las mismas acciones).

• svn commites una cosa diferente a git commit.
• las ramas en svn y git son muy diferentes
• un repositorio svn es más como un control remoto git (pero no realmente)
• un repositorio de git es más como una copia de trabajo svn (pero no realmente)

Estas son dos herramientas divididas por un lenguaje común.

Su pregunta, y la mayoría de las otras respuestas, suponen que git es algún tipo de svn ++; Un "mejor svn". No lo es Las dos son herramientas diferentes que funcionan en el mismo espacio, como un automóvil y una motocicleta.

Te sugiero que elijas uno, lo domines y comiences a usarlo en tu equipo. Aprender el control de versiones será difícil para las personas que no lo han usado antes. Su VCS será una parte importante de su infraestructura, y aprender a confiar en él implica desarrollar nuevos hábitos de trabajo. Eso lleva un tiempo.

(De cualquier manera, asegúrese de que sus administradores de sistemas hagan una copia de seguridad del repositorio maestro; perder el control de la fuente sería catastrófico).

Probablemente no: hay suficientes diferencias entre el servidor y el distribuido que probablemente solo te confundirían aún más.

Comience desde el principio a seguir las buenas prácticas con el DVCS de su elección como si fuera desde cero y probablemente será mucho más feliz.

Ve a Mercurial (si no quieres sentirte abrumado).

Git es solo marginalmente más complicado que Subversion, porque hay una distinción en Git entre comprometerse y empujar al repositorio central.

Vale la pena aprender Git mientras tienes la oportunidad de que Subversion destruya tu mente.

No creo que sea necesario entender Subversion para entender a Git.

La mayor diferencia con Git y Mercurial de Subversion, al menos para mí, es que tiene un repositorio local con el que trabaja, ingresa y sale de allí hasta que su código esté funcionando, finalice la compra desde el repositorio central, solucione cualquier conflicto y Vuelva a ingresar y empuje al servidor.

Realmente me gusta git en el entorno Unix (Linux, MacOS X). En Windows, es un poco hacky. Consideraría Mercurial si tengo Windows en la ecuación.

Me gustaron tus clases de historias, prueba SCCS, RCS, CVS, Subversion y luego usa algo útil como Git o Mercurial.

Git y Mercurial son equipotentes, la gran ventaja de Git es github . Pero si no desea externalizar su control de versiones, github ya no está en la ecuación.

Los sistemas de control de versiones comparten algo en común con los lenguajes de programación en que el primero que aprendas tomará más tiempo. Después de eso, elegir uno nuevo es solo una cuestión de aprender cómo los conceptos centrales son expresados ​​por el nuevo sistema.

Puedes aprender Git ahora e invertir tiempo en aprender Suvbersion más tarde si es necesario.

No Descargue Git, cree una cuenta de github y juegue un par de días bifurcando repositorios, etc. Git es bastante trivial para ponerse al día. Aprenda 5 o 6 comandos bash y podrá realizar todas las tareas esenciales. Generalmente prefiero la "prueba de idiotas" de una GUI, pero el Git Bash es tan fácil como parece. Además, el Git Gui es bastante decente si prefieres esa ruta. Realmente no veo el beneficio que verías al aprender SVN. Pasé un tiempo en el que estaba evaluando algunos sistemas de control de versiones diferentes para un nuevo proyecto de código abierto. Probé SVN, Bazaar, Git y un par más y aprendí los conceptos básicos de cada uno. YMMV, pero Git fue, con mucho, el más fácil. No hay nada de malo en aprender SVN también, pero realmente no te ayudará a aprender Git.