¿Por qué es tan difícil aprender Git?

Answer 1

Git no es difícil para todos, sino para la mayoría de las personas que viven en el mundo.

En mi opinión, serás tratado como un ciudadano de segunda clase por git:

• Si eres usuario de Windows
• Si no eres adicto a cualquier software de terminal

Y la vida es dura para todos los ciudadanos de segunda clase.

No hay un mejor cliente GUI para git. Hay muchos clientes increíbles, pero “muchos” es el problema clave. Como principiante, tiene que aprender de su compañero de trabajo, tutorial, sitio Q / A como Stack Overflow. Y la mayoría de ellos no demuestran las características utilizando ningún cliente GUI que haya instalado. Actualmente estoy trabajando en una empresa de software local donde se utiliza git como herramienta de control de versiones, pero ninguno de mis colegas tiene conocimientos básicos sobre git / vcs, lo cual es necesario para trabajar en un entorno compartido. Desafortunadamente, algunos de mis compañeros de trabajo han sabido que tengo mejor conocimiento sobre git que otros en la compañía. Y a menudo vienen a mí, pero a veces no puedo resolver sus problemas en su máquina. Porque usan diferentes clientes de GUI que nunca he usado y no me interesa aprenderlos. Otro problema es que git terminal proporciona su mejor soporte para Linux, luego Mac (sin autocompletar por defecto), luego Windows (probablemente el peor soporte). Git proporciona soporte de Windows mediante un MinGW integrado y como no me gusta el símbolo del sistema de Windows, así como Power Shell, personalmente uso Cygwin como terminal. Pero me resultó difícil usar git desde ambos lugares. Por ejemplo, tengo que agregar ssh-key en ambos archivos de usuario.

Desde el punto de vista del diseño de UX, “peor es mejor”. Y de acuerdo con mi observación, git y mercurial son los vcs más útiles entre todos los otros vcs populares. Y confíe en mí, si git proporcionara todas las funciones que un usuario pueda necesitar, entonces sería el vcs más difícil del mundo y nadie podría aprenderlo. Es cierto para cualquier software. Debe sacrificar todas las funciones impresionantes que son muy necesarias para los usuarios avanzados solo para facilitar el aprendizaje para los usuarios novatos. Aunque la mayoría de los softwares están diseñados de esta manera, los usuarios novatos son la mayoría del mundo.

Afortunadamente, Linus no diseñó el git solo para los usuarios novatos. Probablemente tenga algún rincón suave para los usuarios avanzados o no sabía cómo hacer una UX “fácil de aprender”. Por lo tanto, si desea aprender git solo para algunas funciones básicas, puede pensar que su UX está mal diseñado y podría rediseñarse para facilitar el aprendizaje. Pero confía en mí, solo estás pensando desde la perspectiva del usuario novato. Recuerde, todos los usuarios avanzados deben aprender el software todos los días. No tienen ninguna capacidad inherente para aprender software de la noche a la mañana, aunque algunas personas están acostumbradas a pensar de esa manera. Por lo tanto, no es justo pensar que los usuarios avanzados podrían haber usado / aprendido git de todos modos, incluso si git fue diseñado para usuarios novatos.

Si comparo mi experiencia de aprendizaje entre git y mercurial, encontré que mercurial es más fácil de aprender y enseñar en la etapa inicial en comparación con git. Pero cuando intenté aprender algunas características más avanzadas, como el sub-repositorio / sub-módulo / sub-árbol, descubrí que Mercurial tiene muy pocos apoyos para ello.

Además, mercurial utiliza el etiquetado del nombre de la rama en el mensaje de confirmación, que es realmente útil cuando los usuarios no son tan cautelosos con respecto a la estructura del árbol (cuándo fusionarse sin adelantar y cuándo simplemente cambiar la base de confirmación en lugar de fusionar). Pero si todos los usuarios tienen cuidado en fusionar las estrategias del repositorio, el etiquetado forzado del nombre de la rama en el mensaje de confirmación puede parecerles molesto. Sin embargo, personalmente, prefiero mercurial branch sobre git branch, especialmente cuando uso con un UI Client.

Una desventaja de usar git desde el terminal es que no puede ver el árbol de revisiones todo el tiempo. Tienes que memorizar de alguna manera la estructura del árbol mientras escribes los comandos git en la terminal. Creo que el árbol de revisión, los archivos agregados y algunas otras cosas deberían estar visibles por defecto en git terminal.

Answer 2

Git es difícil de aprender porque la gente trata de aprender todo a la vez.

Esto se vuelve abrumador y nos llevaría a creer que aprender git es difícil. Sin embargo, estudiar lentamente y aprender solo lo que necesita, en última instancia, le facilitará a usted aprender git y entenderlo mejor.

Ahora, ¿cómo vas a aprender git más fácil? Trato de simplificar las cosas tanto como sea posible y apegarme a lo básico.

Comience con el concepto de control de versiones . ¿Por qué incluso lo necesitamos? Deberías poder responder a esta pregunta. Después de eso, deberías tener una buena idea de por qué necesitamos una “herramienta” como git.

El siguiente es el flujo de trabajo básico de:

1. Halar
2. hacer algún cambio
3. cometer
4. empujar

Estos deben ser todos los conceptos que necesita para comenzar. No hay necesidad de entender la fusión y la reorganización, ya que esto complicará las cosas. Entienda primero los conceptos anteriores, luego continúe y estudie “fusionar” y “rebasar” después.

Una vez que empiece a usar git diariamente en su flujo de trabajo, obtendrá una mejor idea de ello y se convertirá en algo natural.

Además, descubrí que usar GUI Tools / Clients me ayuda mucho cuando estaba tratando de aprender git. Si la línea de comandos es difícil de entender, un enfoque visual de git podría ser útil y te haría comprender mejor lo que está sucediendo.

Answer 3

Git es difícil de aprender porque sus desarrolladores renunciaron a facilitarlo.

El comando Git que todos conocemos y “amamos” hoy en día estaba pensado originalmente para ser una capa de bajo nivel que otros programas más fáciles de usar usarían como intermediarios.

Hablaron de ello utilizando las tuberías de agua como una metáfora: este comando estaba destinado a ser la “tubería”, que se esconde dentro de las paredes haciendo el trabajo real, mientras que los otros programas serían la “porcelana”, que se conecta a la tubería y da Los usuarios tienen algo agradable de tocar (o sentarse).

Pero a medida que pasaba el tiempo, los desarrolladores se familiarizaron tanto con la “plomería” y sabían mucho sobre qué comandos de bajo nivel se combinaban para realizar tareas de alto nivel, que decidieron que no necesitaban ninguna “porcelana” en la parte superior. ¡después de todo! Si los tubos de metal desnudo fueran suficientes para ellos, razonaban, serían lo suficientemente buenos para todos los demás.

Ahora estamos atrapados con esa decisión.

Esta página de Git koans analiza algunas de las formas en que las decisiones de diseño de Git aún nos persiguen. Por ejemplo, expone abstracciones internas directamente al usuario, incluso cuando no está claro para los usuarios por qué varios conceptos diferentes en su propia mente se asignan a lo mismo en Git:

Un programador de UNIX estaba trabajando en las granjas de cubículos. Cuando vio al Maestro Git viajando por el camino, corrió a su encuentro.

“¡Es un honor conocerte, Maestro Git!”, Dijo. “He estado estudiando la forma en que UNIX diseña programas para que cada uno haga una cosa bien. Seguramente puedo aprender mucho de ti.

“Seguramente”, respondió el maestro Git.

“¿Cómo debo cambiar a una rama diferente?”, Preguntó el programador.

“Utilice git checkout “.

“¿Y cómo debo crear una rama?”

“Utilice git checkout “.

“¿Y cómo debo actualizar el contenido de un solo archivo en mi directorio de trabajo, sin involucrar a las sucursales?”

“Utilice git checkout “.

Después de esta tercera respuesta, el programador se iluminó.

Y debido a que el programa creció orgánicamente, un caso de uso específico a la vez, sin un plan coherente, puede ser difícil recordar cómo hacer cosas similares en diferentes casos de uso:

Un principiante estaba aprendiendo a los pies del Maestro Git. Al final de la lección, leyó sus notas y dijo: “Maestro, tengo algunas preguntas. ¿Puedo preguntarles?

El maestro Git asintió.

“¿Cómo puedo ver una lista de todas las etiquetas?”

“Git git tag “, respondió el maestro Git.

“¿Cómo puedo ver una lista de todos los mandos a distancia?”

“Git git remote -v “, respondió el maestro Git.

“¿Cómo puedo ver una lista de todas las sucursales?”

” git branch -a “, respondió el maestro Git.

“¿Y cómo puedo ver la rama actual?”

“Git git rev-parse --abbrev-ref HEAD “, respondió el Maestro Git.

“¿Cómo puedo eliminar un control remoto?”

“Git git remote rm “, respondió el maestro Git.

“¿Y cómo puedo eliminar una rama?”

“Git git branch -d “, respondió el maestro Git.

El principiante pensó por unos momentos, y luego preguntó: “¿Seguramente algunos de estos podrían hacerse más consistentes, para que sean más fáciles de recordar en el momento de la codificación?”

El maestro Git chasqueó los dedos. Un hobgoblin entró en la habitación y se comió vivo al novicio. En la otra vida, el novicio se iluminó.

Fundamentalmente, los conceptos detrás de Git no son tan difíciles de entender.

Si conoce un sistema de control de versiones no distribuido, como Subversion, entonces aprender sobre el control de versiones distribuido es bastante fácil. Es casi lo mismo, excepto que no hay un repositorio central; Cada uno tiene su propia copia del repositorio. Solo necesita aprender dos acciones nuevas, “jalar” y “empujar”, y la acción “fusionar” que ya sabe será mucho más importante.

Si conoce otro sistema de control de versiones distribuido, como Mercurial, entonces ya conoce todos los conceptos importantes que necesita para Git. Pedazo de pastel, ¿verdad?

La parte difícil es que Git usa nombres desconocidos para todo . Si conoce un comando en algún otro sistema de control de versiones, como “checkout”, y ve que Git tiene un comando con el mismo nombre, es muy probable que haga algo completamente diferente en Git . Tal vez incluso dos o tres cosas diferentes!

Afortunadamente, hay “hojas de trucos” que puede usar para asignar los nombres de otros sistemas de control de versiones a Git. Con un poco de práctica, ya no necesitarás la hoja.

Si no conoce ningún sistema de control de versiones y está aprendiendo Git desde cero, puede ser una buena idea aprender primero un sistema diferente , donde la interfaz sea más pulida y coherente. Una vez que lo domines, será más fácil traducir esos conceptos al mundo Git.

Answer 4

Soy un ávido lector de Quora, este es mi primer intento de respuesta. Tómelo con un grano de sal.

Git, en mi opinión es difícil de aprender porque tiene un tema difícil, control de versiones distribuido. El control de versiones es difícil por sí solo. Además, no hay una regla que diga que una herramienta no puede ser difícil de usar porque es solo una herramienta. ¿Tal vez te propones entender demasiado a la vez?

Sin embargo, creo que los casos de uso más comunes y básicos de Git no son tan difíciles de detectar:

• creando / clonando un repositorio
• Entendiendo la diferencia entre repositorios remotos y locales.
• Ramificación, creando nuevas ramas que rastrean otras ramas.
• Agregando archivos para ser rastreados, excluyendo archivos
• haciendo compromisos
• empujando cambios locales a remoto
• Difingiendo (la mayor parte del tiempo la punta de diferentes ramas)
• fusionar cambios de otra rama local o remota en la que está trabajando
• tire de las solicitudes, fusionando la punta de una rama en la punta de otra rama
• Revertir el estado a un estado anterior en una línea recta de confirmaciones
• descartando cambios no comprometidos
• esconder los cambios para aplicarlos en otra parte (quizás en otra rama)

No te morderán estos y los comandos también son bastante simples. Se vuelve frustrantemente más difícil a medida que aparecen otros conceptos, como rebasar, seleccionar cereza, revertir compromisos de combinación, etc.

Creo que estos conceptos simplemente no se pueden aprender si intentas aprender todo de una vez desde cero. Simplemente vaya con lo que necesita hasta que necesite algo que no haya hecho antes. Cada uno de los git foo más avanzados vendrá mucho más fácil y estará menos confundido si es solo un paso más allá de lo que ya está seguro.

Los documentos y el libro Pro Git son muy completos, pero no son una hora de dormir ni para el principiante.

Aquí hay algunos recursos que me parecieron inestimables y recomendados a mis colegas también:

Piense como (a) Git es un sitio que utiliza un enfoque heterodoxo. En lugar de sumergirse en los comandos, explica los conceptos básicos de la teoría de gráficos independientemente de Git y luego explica cómo Git emplea gráficos.

git concepts simplified tiene 55 diapositivas concisas sobre terminología y explicación de conceptos básicos e incluso operaciones avanzadas

No lo he usado personalmente, pero Learn Git Branching también se ve muy adecuado para principiantes, con un tutorial interactivo basado en el navegador.

Answer 5

Porque es un producto muy mal pensado que nunca fue diseñado para facilitar su uso. A menudo mal utilizado.

La sintaxis del comando es arcana y misteriosa.

Hay demasiados comandos . Esto es sintomático de tener un enfoque a nivel de implementación, en lugar de un enfoque a nivel de historia de usuario.

Una forma en que sabemos que esto es cierto es mirar a IntelliJ. A menudo proporciona varios comandos Git, solo para hacer una historia de usuario. Al igual que el proceso de registro, puede ocultar cambios, buscar, tirar, cambiar de base, cambiar una rama, tirar, agregar, eliminar, cometer una combinación de avance rápido y empujar.

En un caso así, lo que quiero hacer es “incluir mis cambios en la rama maestra en el sistema de código fuente remoto”.

No quiero tener que acordarme de git add o git rm (¡solo hazlo!), No me importa en absoluto una rápida fusión, una combinación o una rebase (¡hazlo!).

Con mi estilo de codificación personal (pequeños pasos, mucho refactorización), no me importa preservar cada pequeña parte de la historia junto con cada paso de refactor (¡hazlo!)

Y ahora – problemas. He cometido un error. Quiero revertir

¿Desea un maestro de pago, un revertido o un reinicio?

¿Quieres empujar eso? ¿Estás seguro? ¿Alguien más podría no importarle esa historia?

¿Le gustaría papas fritas con eso?

Git ha ganado una notable tracción por algo tan difícil de usar. Realmente no puedo ver a Apple lanzando el ‘Apple Git Phone’, donde cada dos segundos dice ‘trataste de hacer una llamada en GSM con la antorcha encendida y un SMS esperando mientras jugabas en Facebook. “¿Quieres unir rápidamente la llamada, o combinar Facebook, o arreglar los filtros de LED?”

Hice todo eso, pero es un balbuceo similar al de Git.

Git es mucho peor en Eclipse. EGit no juega muy bien con Git merge. Esto no ayuda.

Git también está diseñado para

• Un equipo distribuido
• Trabajando en código C, sin inyección de dependencia OOP o interfaces
• Con cambios en ramas separadas.
• Eso lleva mucho tiempo cada uno
• ¿Quiénes están obligados a pedir permiso para registrarse?
• Que puede ser rechazado. A menudo con juramento extremo.
• Para lanzamientos infrecuentes.

Considerando que mi lugar de trabajo utiliza

• OOP modularidad
• Integración continua a una rama principal.
• Lanzamientos diarios / semanales
• Por un equipo habilitado para facturar.

Este es un conjunto de casos de uso completamente diferente. Git apoya el primero. Y casi se las arregla para apoyar a este último.

En resumen, Git es difícil de aprender por diseño.

O más bien, una falta flagrante de diseño de experiencia de usuario .

(Ahhh. Me siento mejor.)

EDIT: Algunos comentarios válidos sobre CI y OO no causan ningún problema. Estoy de acuerdo. Un poco de inglés torpe por mi parte. La forma particular en que tenemos la configuración de CI en nuestro equipo significa que, en efecto, solo existe una única sucursal de Git que importa. Hay otras formas. Y la forma en que divido el código utilizando, a medida que sucede, la OOP está destinada a minimizar la cantidad de conflictos de combinación, simplemente haciendo que los archivos sean más pequeños y estén más enfocados. No es la única forma de hacerlo, estoy de acuerdo.

También estoy de acuerdo en que Git es una excelente tecnología de control de fuente, con una serie de ventajas en el manejo de sucursales, clonación rápida, almacenamiento de repositorios completos, detección de cambios de archivos basados ​​en hash y cómo comprime los archivos para transferirlos rápidamente. Mi punto fue, y sigue siendo, con respecto a la Experiencia del usuario de su vasto e inconsistente conjunto de comandos.

Answer 6

El problema principal con git es que hay demasiadas formas de hacer las mismas pocas cosas, conceptualmente simples.

Es el perl de los sistemas de control de código fuente. Esto no es un cumplido.

Debido a esto, incluso dentro del mismo grupo de desarrollo, dentro de la misma compañía, generalmente no existe un modelo de flujo de trabajo estandarizado.

---

Esencialmente, esto significa que sus compañeros de trabajo no son de ninguna utilidad para aprenderlo: cada uno tendrá sus flujos de trabajo individuales, ya que tendrán orígenes diferentes y es probable que hayan usado git de diferentes maneras en diferentes grupos, o incluso en diferentes compañías, o Dentro de sus propios proyectos, o en la universidad.

Si quieres hacer algo y le preguntas a 3 compañeros de trabajo diferentes, obtendrás 4 formas diferentes de realizar la tarea.

Si necesita volver a hacer la misma tarea, pero es bastante raro, y no puede recordarlo, y no pregunta exactamente de la misma manera, quizás obtenga otras 4 respuestas de los mismos 3 compañeros de trabajo. Sin embargo, debido a que no realizó la pregunta de la misma manera, puede haber una superposición completa o nula entre estos conjuntos de respuestas para “cómo realizo esta operación”.

Esto es extremadamente frustrante si estás empezando.

---

La única solución para esto es aprender todo git . Le puede llevar meses de frustración descubrir este hecho, particularmente si ha usado Bitkeeper, Perforce, CVS, SVN, RCS, SCCS, PVCS, VSTS, Visual SourceSafe, Mecurial, etc.

En otras palabras: sistemas de control de código fuente escritos por seres humanos racionales y sanos que temen que algún día tengan que hablar con alguien sobre su uso en una llamada de soporte técnico.

Así que aprende todo de git.

No confíe en otros seres humanos, a menos que su compañía. Grupo tenga un flujo de trabajo documentado para seguir cuando use git. Si lo hacen, prepárate para que esto no sea el caso, si alguna vez trabajas en otro lugar que también use git.

Así que aprende todo de git.

Si esto parece una gran curva de aprendizaje para algo que es conceptualmente simple y, por lo tanto, también debería ser simple desde el punto de vista procesal … tienes razón. Es.

Así que aprende todo de git.

Esto no es tan difícil como parece; solo requiere una buena memoria, leer toda la documentación y probar todo lo que se puede probar varias veces cada uno.

Piense en ello como una prueba de coeficiente intelectual que Linus ha establecido para que pueda filtrar a las personas que cree que son incapaces de aportar código útil al kernel de Linux.

Y entonces algún idiota decidió usarlo para algo más que Linux.

Así que aprende todo de git.

---

Al final: se alegrará de haberlo hecho, si tiene que usarlo como parte de su trabajo.

Y cuando la nueva persona comienza en su grupo, y en lugar de preguntar a 3 personas y obtener 4 respuestas, también puede preguntarle a usted, para un total de 4 personas.

Y si ha aprendido todo el git, como he aconsejado, ahora tendrán 5 respuestas con las que lidiar, para la misma operación que debería ser un flujo de trabajo simple y estandarizado.

Y si realmente te has comprometido con la tarea, para aprender todo el git … tal vez tengan 7 respuestas con las que lidiar, mientras maldicen a las almas negras y negras de sus compañeros de trabajo.

Y entonces serás un maestro git.

Answer 7

Porque probablemente como la mayoría de la gente, te saltaste lo básico. La mayoría de la gente elige la fuente incorrecta para aprender Git, o elige la correcta pero asume que puede omitir las partes introductorias.

Hay cientos de tutoriales de Git, pero el 99% de ellos trata sobre los comandos que se deben ejecutar para obtener algún resultado, en lugar de comprender realmente el modelo mental.

La documentación en git-scm.com es una de esas muy pocas fuentes que explican a Git de la manera correcta, particularmente en esta página – Primeros pasos – Conceptos básicos de Git.

Aparentemente, las personas en git-scm son muy conscientes de la importancia de no saltarse los conceptos básicos. Incluyeron lo siguiente en el párrafo 1:

Esta es una sección importante para absorber, porque si entiendes qué es Git y los fundamentos de cómo funciona, entonces usar Git efectivamente será mucho más fácil para ti.

¿Por qué las personas tienden a saltarse lo básico? Probablemente sea una combinación de lo siguiente:

• Saltarse lo básico funcionó para ellos con la mayoría de las otras herramientas
• Escogen el tutorial equivocado
• No se dan cuenta de que el modelo git puede ser sustancialmente diferente de lo que saben sobre el control de versiones.
• Necesitan algo ahora mismo, es más fácil simplemente copiar / pegar un comando de una hoja de trucos web o preguntar a un compañero de trabajo
• Necesitaban algo “en este momento” en varias ocasiones y, después de algunas veces, sienten que ya saben lo suficiente y no aprenderán nada nuevo leyendo los conceptos básicos.

Answer 8

Oh, vamos, Git no es difícil! Así es como dominas a Git:

1. Ir a Google. Escriba “el mejor cliente Git para” + Windows || macOS || Linux, dependiendo de su plataforma.
2. Llegó al sitio web. Descargue e instale la GUI del cliente Git.
3. Aprende lo básico del cliente Git:

1. configurando un repositorio
2. revisa
3. cometer
4. revertir
5. unir
6. ramas
7. etiquetas
8. mandos a distancia

Comience a usar Git.

Aprende el resto poco a poco a medida que avanzas.

En serio, no sé la mitad de la sintaxis de Git, pero ¿a quién le importa? Mis casos de uso típicos son bastante sencillos, y tengo toda la Internet como referencia para cualquier cosa más complicada que lo que sé.

Para su información, TortoiseGit es una implementación GUI altamente funcional, aunque un poco complicada. Ocultar tanta funcionalidad dentro de un menú contextual en el Explorador de Windows es un poco extraño, pero funciona. En macOS, uso un cliente Git simple (recuerda, mis casos de uso son simples) llamado GitX. No hace mucho, pero lo que hace, lo hace muy bien.

Y sí, Git es super-nerdy y su sintaxis de comando es inconsistente, pero internamente, arquitectónicamente, funciona muy bien, lo cual era una especie de punto al que Linus Torvalds estaba tratando cuando lo escribió inicialmente. Nada más se acerca.

Answer 9

Flujo de trabajo estándar,

paso 1, `git clone http: // the-git-url ( http: // the-git-url )`

paso 2, hacer edición de código

paso 3, `git add files`. Normalmente ejecuto `git add -u` si acabo de editar archivos que ya están bajo el control de git

paso 4, `git diff —cached —stat` para volver a verificar los archivos que enviarás

paso 5, `git commit -m ‘commit message’`

paso 6, `git pull -r origin master`, si hay conflictos,` git mergetool` para resolver conflictos

paso 7, `git show && git push origin master`, revise y presione el código.

Eso es bastante simple. Dedique 15 minutos a comprender estos 7 pasos, luego domina cada software de control de versiones (rendimiento, subversión, clearcase, …)

Git le ofrece más funciones GRATUITAMENTE (el software de control de otra versión le ofrece una versión inválida, luego le pide que pague por los llamados complementos de terceros), pero está totalmente bien que no aprenda esas características al principio (filial, fusión … ).

Sugiero leer Git – Libro (Git – Libro). Capítulo 1, 2 es suficiente para el uso diario. Puedes leer el capítulo 3 si estás interesado en bifurcar.

En el Capítulo 7, la sección 7.1, 7.2, 7.3, 7.5, 7.6 son útiles para usuarios avanzados. La sección 7.4 es útil si trabajas para un proyecto de código abierto.

Antes de leer ese libro, puede leer algunos tutoriales sobre `GNU patch` y` GNU diff` para tener una idea de cómo administrar el código si no existe el software de control de versiones.

Considera a git como una rara oportunidad de aprender realmente la habilidad de control de versiones. La habilidad es extremadamente útil para todos, no solo para desarrolladores. Por ejemplo, uso git para administrar mis cuentas bancarias.

Answer 10

¡CONFÍE EN MÍ NO ES !!

Vamos a empezar a subir la escalera de Git.

1. Primer paso: ¿Por qué quieres aprender Git?

Todos tienen sus propios requisitos para comenzar a aprender Git. Es posible que lo necesite porque desea contribuir a Open Source, puede que lo necesite para conservar sus cosas o simplemente desee aprenderlo. Necesita la razón para aprender algo, para mantenerse motivado, de lo contrario, podría encontrarlo difícil y renunciar con el tiempo. Encuentra esa RAZÓN y MOTIVACIÓN para Git y comienza.

2. Segundo paso: ¿Qué aprender?

Git es un mundo enorme en sí mismo para explorar. Necesita saber qué quiere aprender según sus requisitos, por ejemplo: si no necesita sucursales en Git, ¿por qué debería aprenderlo? (aunque es esencial 😉) Para empezar:

• Aprende a bifurcar y crear un repositorio.
• Aprende a clonar un repositorio.
• Aprende a cometer y empujar cambios.

3. Tercer paso: ¿De dónde aprender?

Ok, ahora sabes lo que quieres y por qué lo quieres. Vayamos a cómo conseguirlo. Estos son algunos lugares que personalmente prefiero y recomiendo:

• Git – Documentación
• Aprende Git con Bitbucket Cloud
• Encuentra algunos videos en Youtube. Los conseguirás fácilmente.

4. Paso final:

Ahora que conoce los conceptos básicos y hasta este paso podría haber comenzado a implementarlos. Ahora estás en la parte superior de la escalera. Mire a continuación cuánto ha aprendido. Ahora es el momento de verificar si omitió algo. Vuelve al paso 2 ahora y cambia ¿Qué aprender? ¿Qué más aprender? y continúe el proceso hasta que sea lo suficientemente competente como para no encontrarlo difícil.

Esta es una buena manera de aprender los sistemas de control de versiones y todo sobre Git en 3 días divyam3897 / VersionControlSystems

Happy Learning Git !!

Answer 11

Visual Studio y TFS me echaron a perder, y cuando tuve que usar Git, lo odiaba.

Fue difícil para mí por las siguientes razones:

1. Falta de visualización: soy más un pensador visual, y la mejor manera de entender las cosas es visualizarlas. Si bien entendí los conceptos de bifurcación y revisiones, no fue capaz de visualizar todo lo que me agonizaba.
2. Su terminología era diferente de Visual Studio. Cometer, empujar, tirar tenía diferentes alcances. Tardé un poco en acostumbrar mi cerebro a las diferentes terminologías.
3. La fusión y la comparación fueron molestas debido a la falta de una interfaz de usuario amigable. Visual Studio le permite ver el antes y el después de los archivos, git muestra el antes y el después de los cambios en el mismo archivo con id de confirmación estúpida. ¿Por qué no pueden mostrar el comentario de confirmación junto con el ID? No lo sé, obviamente nadie le preguntó a una persona de UX por dos centavos.
4. No es intuitivo, y toma demasiado tiempo para que uno aprenda los conceptos básicos considerando su propósito. Su propósito era proporcionar control de la fuente, y eso no debería tomar más de una hora para que un novato aprenda. Lamentablemente, incluso con la ayuda de mis compañeros de trabajo y la experiencia de trabajar con Linux y las cosas de la línea de comando, todavía tuve problemas para realizar la fusión y el empuje básico después de un día entero.

Answer 12

Git es difícil de aprender. Eso es verdad. Sin embargo, para mí, la razón no es sus comandos o diseño general. Es el concepto y la terminología. Algunos ejemplos:

1. El concepto de SCM distribuido donde el repositorio de cada usuario puede ser * el * central, es difícil de entender para alguien que viene de otros SCM como CVS, SVN, etc. Para mí, lo fue.
2. Misma terminología, funcionalidad diferente. Caso en punto – pago y envío. En SVN, la verificación se usa para copiar / clonar el proyecto o el código del repositorio central. En git, el checkout se utiliza principalmente para moverse entre ramas.
3. Concepto de las ramas. En SVN, una rama es similar a una carpeta. La razón de esto es porque en SVN un compromiso no puede tener varios padres. Sin embargo, en las ramas de git son, simplemente, un conjunto de confirmaciones que pueden tener varios padres. Por lo tanto, el concepto de ramas varía de manera diferente en ambos.
4. Cometer. Este fue el más frustrante para mí. En SVN, cometer significa cometer en el repositorio central. Sin embargo, en git commit está relacionado con su repositorio local. Tienes que presionar si quieres sincronizarlo con un repositorio remoto.

Incluso con los ejemplos anteriores, una vez que captas los conceptos de git, se siente más intuitivo que otros SCM. Esa ha sido mi experiencia.

Answer 13

Git es difícil de aprender porque no abstrae completamente su arquitectura. Usar git correctamente requiere entender los aspectos internos de cómo funciona git. Probablemente es la mayor crítica que puedes imponer sobre ella. Git es rápido. Git es brillante. Git está bien diseñado. Git es poderoso. Git es característica completa. Git es flexible. Git es extensible.

Lo que no es, está bien abstraído. El nombre de un commit * es * el sha1 utilizado por el modelo de datos para referirse a él. El nombre de un árbol * es * el sha1 del objeto de árbol que lo representa. Una rama no es un concepto complejo, sino una cadena de 40 bytes escrita en un archivo. Un “puntero” en bruto a un commit. Los enlaces simbólicos, como HEAD, son la misma cosa, excepto que apunta a otro puntero. Todo esto tiene mucho sentido para un programador en C, o un desarrollador del kernel, pero es mucho más difícil de explicar a un estudiante de CS o un recién llegado al control de versiones. Y sin embargo, usar git correctamente casi requiere comprensión de ello. Los autores y mantenedores hicieron muy poco esfuerzo por ocultarlo (probablemente porque, en su opinión, hacerlo dificultaría que las personas que * entienden * esas cosas lo usen).

En pocas palabras, git está optimizado para las personas que están dispuestas a dedicar tiempo para entenderlo realmente a un nivel bajo, en detrimento de sus usuarios más informales.

Answer 14

No estoy seguro de por qué a GIT le resultaría difícil aprender. Tal vez usted está apegado a usar el control de código fuente de una manera que no sería natural para GIT?

He plagiado descaradamente muchas de las cosas de la URL adjunta a continuación. Destaca muy bien los pensamientos que me parecen importantes sobre cómo debe fluir el control de la fuente. GIT hace esto trivial cuando este tipo de proceso es su objetivo.

Intenta leer el blog y pensar en GIT de una manera nueva y quizás sea más obvio.

Un exitoso modelo de ramificación Git.

También rara vez soy uno para predicar herramientas GUI. He estado usando GIT exclusivamente en la línea de comandos durante años. Acabo de cambiar a GitKraken. Esta es una muy buena herramienta para visualizar lo que está pasando en todos los repositorios. Especialmente cuando el equipo codifica un lanzamiento. #LuxuriousSourceControl. Quizás también ayude? Aunque generalmente recomiendo aprender la línea de comandos incluso si su objetivo es usar una GUI.

Git GUI Client para Windows Mac y Linux | Axosoft GitKraken

Answer 15

Nada es “difícil de aprender” si estudias metódicamente. El principal problema con git es que la mayoría de las personas (sí, incluso las personas que han trabajado en software durante años) esperan aprender git al memorizar un montón de comandos sin entender realmente el funcionamiento interno.

Cuando estaba en la universidad, un amigo quería comenzar a usar git para trabajar en un proyecto juntos. Solía ​​odiarlo. Como sucede a menudo, odiamos lo que no entendemos. Tomó un tiempo tener una epifanía y eso vino con la siguiente oración:

Un repositorio git es un árbol.

Esta oración de 6 palabras (además de comprender que git es, a diferencia de svn, un sistema descentralizado en el que eliges un repositorio “principal”) cambió completamente la forma en que veo un repositorio de git y me permitió 1) entender qué diablos estaba haciendo al emitir comandos, 2) abstraerse de los comandos individuales e imaginar los cambios en la estructura de datos (el árbol) en lugar de archivos y directorios.

Hace algún tiempo escribí un artículo sobre aprender git:

Cómo trabajar en equipo: control de versiones y git.

Es un poco largo, pero traté de explicar las cosas lo más claramente posible. No dude en hacerme saber si hay algo que no entiende o si ve un error en el artículo.

Y para el 90% de los equipos / proyectos, la totalidad de los comandos git que necesitarás son:

• clon / init
• Halar
• cometer
• empujar
• Reiniciar
• rebase
• unir

Answer 16

He estado usando Git durante casi tres años y, francamente, utilizando shells gráficos conocidos y bien documentados, como el git tortuga en Windows y gitk en Linux, creo que se puede usar fácilmente, siendo productivo desde el primer día, una vez que se conocen los conceptos básicos.

Una vez que lo usa para resolver problemas reales de desarrollo de software, se familiariza con sus características esotéricas lentamente y comprende que todas las piezas, incluso las más extrañas y complicadas, tienen su lugar específico.

El desarrollo de software es difícil, git es difícil como consecuencia de esto, pero la mejor manera de aprender algo en TI es usarlo, en mi humilde opinión, y no solo aprender de memoria docenas de manuales en pdf.

Answer 17

Estoy de acuerdo contigo, Git es difícil de aprender. Me tomó más de un año antes de que pudiera decir que me siento cómodo con git. Sigue la misma filosofía que otras herramientas de programación / lenguaje como Vim / Perl: difícil de aprender pero fácil de usar. Esta filosofía funciona porque solo aprendes una vez pero usas muchas veces. Git te permite hacer cosas que otros competidores como SVN no pueden. Mi experiencia laboral me expuso a SVN, ClearCase, Accurev y CVS. Aprecio que Git me permita:

• Cambiar ramas al instante
• No tener que almacenar sucursales diferentes localmente en carpetas separadas
• Cambiando la historia, incluyendo el cambio de base, cometer
• selección de cereza
• cometer por líneas

Una vez que entendí cómo funciona Git y lo dominé, siento que nunca podría volver a usar ninguna otra herramienta que no me ofrezca las mismas funcionalidades.

Espero haberte convencido para que sigas aprendiendo Git. Si no quiere lidiar con el terminal y no necesita hacer cosas por adelantado demasiado, puede usar algunos de estos clientes de Git GUI. Aparentemente, no tienen tantas funcionalidades como la versión de línea de comandos, pero deberían ser suficientes para comenzar:

• SourceTree | Git y Hg Client gratis para Mac y Windows
• GitHub Desktop
• Git – Documentación git-gui

Answer 18

¿Sabes que? Solía ​​pensar esto cuando lo encontré por primera vez. De hecho, lo ridiculicé públicamente porque los clientes de Git que estábamos usando en ese momento me molestaban y eran tan asesinos de productividad que casi tiré las computadoras. Maldié a Git, maldije a Linus, maldije a todos los usuarios de Git y trabajando a 200 metros de mí, ¡me oyes gritar!

Decidí que no podía continuar así, así que tuve que volver a lo básico. Pasé un fin de semana aprendiendo usando nada más que Bash. ¿Sabes que? ¡Los momentos de la bombilla vinieron gruesos y rápidos y terminé absolutamente amoroso! Como alguien que ama el aprendizaje, se convirtió en una alegría absoluta en varios frentes diferentes. Se convirtió en el primer sistema de control de versiones que siempre llamé “hermoso” y cuando esas cosas raras salen mal, casi siempre son exquisitamente fáciles de arreglar. No se pudo obtener suficiente! Me encanta y el ecosistema que crece a su alrededor.

Confía en mí, vuelve a lo básico, pruébalo. Encuentra un gran comienzo rápido y solo úsalo. Parte del problema son los conceptos en torno al control de versiones distribuido y centralizado. Eso obliga a la introducción de una rebase, un empuje, un tirón, etc. Por encima de lo que ya sabes. Luego está la belleza de la cosecha de cerezas, los aplastantes, etc. Esos son brillantes por varias razones.

Dale tiempo dedicado. ¡No te arrepentirás!

Answer 19

¡No es!

Al menos para mí, solo trabajar en proyectos para un jugador, es bastante simple. Yo uso los siguientes comandos:

git clone # Comenzando un nuevo proyecto
git pull # Obteniendo la última revisión en mi otra computadora
git commit # preparándose para empujar
git push # Empujando cambios locales al servidor
git add # Cuando se necesitan nuevos archivos
git rm # Cuando los archivos ya no son necesarios.

Cualquier otra cosa, busco en google

Lo único extraño para mí es la división entre “git commit” y “git push”. Siempre uso estos dos comandos uno tras otro, por lo que nunca hago un uso separado del área de preparación.

De todos modos, lo anterior funciona para mí.

Answer 20

Porque ofrece tantas opciones. Tomemos, por ejemplo, el caso de uso simple de querer tomar cambios que usted haya hecho y juntarlos con los de todos los demás, una fusión. Eso es algo que está en cada VCS. Sin embargo, en git ahora tiene varias decisiones que tomar, si:

1. ¿Debería ser rápido o no?
2. ¿Debes aplastar tus compromisos?

O para hacer las cosas aún más confusas:

1. ¿Deberías estar fusionándote o recogiendo cerezas?
2. ¿Deberías estar fusionando o rebasando?

Cada una de estas opciones tiene un caso de uso y un conjunto de inconvenientes que lo acompañan. Git soporta a cada uno de ellos, y además un millón de opciones diferentes. Pero viene a costa de la complejidad.