Introducción a Git

1

¿Por qué usar un sistema de control de versiones como Git?

2

¿Qué es Git?

3

Instalando Git y GitBash en Windows

4

Instalando Git en OSX

5

Instalando Git en Linux

6

Editores de código, archivos binarios y de texto plano

7

Introducción a la terminal y línea de comandos

Comandos básicos en Git

8

Crea un repositorio de Git y haz tu primer commit

9

Analizar cambios en los archivos de tu proyecto con Git

10

¿Qué es el staging y los repositorios? Ciclo básico de trabajo en Git

11

¿Qué es un Branch (rama) y cómo funciona un Merge en Git?

12

Volver en el tiempo en nuestro repositorio utilizando reset y checkout

13

Git reset vs. Git rm

Flujo de trabajo básico en Git

14

Flujo de trabajo básico con un repositorio remoto

15

Introducción a las ramas o branches de Git

16

Fusión de ramas con Git merge

17

Resolución de conflictos al hacer un merge

Trabajando con repositorios remotos en GitHub

18

Cambios en GitHub: de master a main

19

Uso de GitHub

20

Cómo funcionan las llaves públicas y privadas

21

Configura tus llaves SSH en local

22

Conexión a GitHub con SSH

23

Tags y versiones en Git y GitHub

24

Manejo de ramas en GitHub

25

Configurar múltiples colaboradores en un repositorio de GitHub

Flujos de trabajo profesionales

26

Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master

27

Flujo de trabajo profesional con Pull requests

28

Utilizando Pull Requests en GitHub

29

Creando un Fork, contribuyendo a un repositorio

30

Haciendo deployment a un servidor

31

Hazme un pull request

32

Ignorar archivos en el repositorio con .gitignore

33

Readme.md es una excelente práctica

34

Tu sitio web público con GitHub Pages

Multiples entornos de trabajo en Git

35

Git Rebase: reorganizando el trabajo realizado

36

Git Stash: Guardar cambios en memoria y recuperarlos después

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits viejos al head de un branch

Comandos de Git para casos de emergencia

39

Git Reset y Reflog: úsese en caso de emergencia

40

Reconstruir commits en Git con amend

41

Buscar en archivos y commits de Git con Grep y log

Bonus sobre Git y Github

42

Comandos y recursos colaborativos en Git y GitHub

43

Tu futuro con Git y GitHub

Crea una cuenta o inicia sesión

¡Continúa aprendiendo sin ningún costo! Únete y comienza a potenciar tu carrera

¿Qué es un Branch (rama) y cómo funciona un Merge en Git?

11/43
Recursos

En GIT, una rama o branch es una versión del código del proyecto sobre el que estás trabajando. Estas ramas ayudan a mantener el orden en el control de versiones y manipular el código de forma segura.
Por defecto, el proyecto se crea en una rama llamada Main (anteriormente conocida como Master). Cada vez que añades código y guardas los cambios, estás haciendo un commit, que es añadir el nuevo código a una rama. Esto genera nuevas versiones de esta rama o branch, hasta llegar a la versión actual de la rama Main.

Cuando decides hacer experimentos, puedes generar ramas experimentales (usualmente llamadas development), que están basadas en alguna rama main, pero sobre las cuales puedes hacer cambios a tu gusto sin necesidad de afectar directamente al código principal.

En otros casos, si encuentras un bug o error de código en la rama Main (que afecta al proyecto en producción), tendrás que crear una nueva rama (que usualmente se llaman bug fixing o hot fix) para hacer los arreglos necesarios. Cuando los cambios estén listos, los tendrás que fusionar con la rama Main para que los cambios sean aplicados. Para esto, se usa un comando llamado Merge, que mezcla los cambios de la rama que originaste a la rama Main.

Todos los commits se aplican sobre una rama. Por defecto, siempre empezamos en la rama Main (pero puedes cambiarle el nombre si no te gusta) y generamos nuevas ramas, a partir de esta, para crear flujos de trabajo independientes.

Checkout y merge

Producir una nueva rama se conoce como Checkout. Unir dos ramas lo conocemos como Merge.

Cuando haces merge de estas ramas con el código principal, su código se fusiona, originando una nueva versión de la rama Master (o main) que ya tiene todos los cambios que aplicaste en tus experimentos o arreglos de errores.

Podemos generar todas las ramas y commits que queramos. De hecho, podemos aprovechar el registro de cambios de Git para producir ramas, traer versiones viejas del código, arreglarlas y combinarlas de nuevo para mejorar el proyecto.

Solo ten en cuenta que combinar estas ramas (hacer “merge”) puede generar conflictos. Algunos archivos pueden ser diferentes en ambas ramas. Git es muy inteligente y puede intentar unir estos cambios automáticamente, pero no siempre funciona. En algunos casos, somos nosotros los que debemos resolver estos conflictos a mano.

Aporte creado por: Diego García

Aportes 473

Preguntas 47

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Es muy importante tener un manejo ordenado de nuestro repositorio y para esto existe algo que se llama GitFlow.

GitFlow es una una guía que nos da cierto estándares para manejar la ramificación de nuestros proyectos, es decir, que ramas debemos tener, cuándo y de dónde debemos crear nuevas ramas, cómo debemos nombrar dichas ramas y muchos otros conceptos que nos ayudaran a manejar mucho mejor nuestro repositorio; siendo esto muy importante cuando trabajamos en conjunto con varios desarrolladores.

Algunos enlaces:
Gitflow Workflow

Git-Flow Cheatsheet

Esto es lo que entendi de la clase, espero les ayude 😄

Usar git es cómo ser un Dr. Strange del desarrollo. Movernos entre branches es como moverse en realidades alternas. Hacer merge es unir esas realidades.

| Apuntes|

Como trabajar con Git Flow
Git flow workflow - Historical Branches

Feature Branches

Release Branches

Hotfix Branches

Fuente: . Atlassian

Ramas base de un proyecto en git

🚨🚨🚨 IMPORTANTE! 🚨🚨🚨
A partir del 1 de Octubre del 2020 en los nuevos repositorios la rama principal deja de llamarse MASTER. Ahora es nombrada como MAIN.

Más detalles acá: https://github.com/github/renaming

Compañeros, les comparto un poco de lo visto en clase + mis notas escritas, espero les sirva…#NuncaParemosdeAprender - Compartamos +Y+Conocimiento

Conceptos Básicos:

Un Bug es un error en programación que ocasiona un resultado inseperado.

Merge: Se da cuando los cambios se unen en una rama corta con respecto a la otra.

![](

Hola compañeros, para todos aquellos que esten tomando el curso despues de octubre del 2020, les cuento que debido a una actualización de GitHub, la rama “Master” ha cambiado su nombre por defecto a “Main”. Les informo para que no se lleven sorpresas mas adelante. Un saludo y recuerden nunca parar de aprender ❤️.

Resumen de la clase

Resumen de clase:
Master: Esta es la rama donde se inicia siempre por defecto (se le puede asignar cualquier nombre), a partir de esta rama se crean todas las ramas, en esta rama estan todos los cambios de tus archivos.

Commit: Cada vez que haces una nueva rama lo único que se hace es que copias un commit, que pasa a la rama de a lado, en la cual puedes continuar trabajando sin afectar el flujo de trabajo principal que esta en la rama master.

Development (o rama experimental): Esta es una versión copiada de la rama master, donde experimentás, observás características, featueres entre otros. Para finalmente unirlas a la rama master cuando estén listas.

Bugfixing o Hotfix: Esta rama se encarga de repara cualquier bug, issues (errores) o fallas que surjan en la rama experimental, aquí puedes hacer cualquier clase de cambios para después probarlo en tu rama master.

Checkout: Crea una nueva rama.

Merge: Es una brecha que une dos ramas

Head: Es a donde llevás todo cuando ya tienes tu versión final.

Aqui hay una guia que use para entender git por primera vez… sinceramente les recomiendo que la lean…
https://rogerdudler.github.io/git-guide/index.es.html

Estoy volviendo a ver el curso. Para repasar y tomar notas con Notion

Ahora entiendo la Sagrada Linea de Tiempo de Loki. en Marvel. jajaja… Me volveré un Guardián de ella gracias al Universo Platzi.

Aquí hay una página web para aprender de forma interactiva todo lo relacionado con git.

Estándar común entre desarrolladores de git:

  1. Master – Para producción.
  2. Feature – Para las nuevas características.
  3. Development – Para las pruebas o experimentos.
  4. Hotfix – Para solucionar los errores y unirlas a la rama master.
Wait... Entonces el Master existe en el entorno local y el servidor. ¿Correcto? ... Es decir hay un local master y un remote master.

¡Atómico! A-tó-mi-co.

He quedado enramada 😃

La rama/repositorio por defecto de git es master
Cada commit es una versión en git, y cada versión tiene su código identificador
Crear ramas con el comando checkout
Unir ramas a master con el comando merge

Con la práctica te convertirás en un profesional destacado

🤗

Yo lo veo así, como una forma de entenderlo mejor:

  • Nueva tarea: nueva rama
  • cada paso para completar la tarea: es un commit
  • unir tu tarea completada con las tareas de los demas: merge

Mis apuntes
Una rama representa una línea independiente de desarrollo, es como crear un nuevo área de trabajo con su área de ensayo y su historial. Los nuevos commits se registrarán de forma independiente en el historial la rama, lo que se conoce como forks en el historial del proyecto (término muy empleado en github).

Listar, crear y manejar ramas, git branch
git branch
Este comando lista las ramas locales que existen. La rama en la que estás trabajando actualmente se señala con un asterisco *. La rama master es la rama con la que se comienza en cualquier proyecto, y es la que se utiliza como rama principal donde se encuentra el proyecto en su estado final.

git branch [rama]
Este comando crea una rama con el nombre que elijas.

git checkout experimento
Si hemos nombrado a la rama “experimento”, este comando nos sitúa en esa rama.

Si estábamos en la rama master, teníamos archivos modificados sin añadir o añadidos en el área de ensayo, y nos situamos en la rama experimento con git checkout, éstos cambios se verán en la rama experimento. Hasta que no se haga un commit, los cambios no pertenecerán a ninguna rama.

git branch -v
Este comando muestra el último commit en cada rama.

git checkout -b [rama]
Este código crea una rama y hace checkout directamente en la misma. Es el código que se suele usar ya que cuando se crea una rama normalmente se suele hacer checkout en ella.

Es bastante frecuente crear una rama, hacer los cambios que sean necesarios, unirla a una rama principal y después eliminar la rama que se había creado. De esta forma si has estado haciendo cambios que realmente no han resultado ser buenos puedes deshacerte de la rama con facilidad.

git branch -d [rama]
Este código elimina una rama.

Unir una rama a la rama actual, git merge
Una vez que has trabajado en una rama, lo normal es querer incorporar los cambios a la rama principal. Para unir una rama a la actual se utiliza el siguiente comando:

git merge
Cuando sólo se han añadido o eliminado archivos en una rama, es fácil unirla a la principal. El resultado simplemente será la suma o resta de esos archivos en la principal. Cuando se hacen modificaciones en archivos, incluyendo cambios en los nombres de los archivos, git detecta esos cambios y los adapta automáticamente, pero a veces surgen conflictos.

espero les pueda servir mis apuntes jejeje si hay errores me comentan 😃

Git checkout NO es para crear ramas! es para moverte entre ramas
la creacion de una rama es Git branch + nombre de la rama!

pd: lo digo porque en la descripcion freddy hace referencia a que checkout es para crear una nueva rama!

espero su feedback ❤️

Branch y Merge en Git

En cada repositorio de git vamos a tener una rama (branch) llamada
Master esta rama tiene el resultado final de nuestro proyecto (es decir todos los commit)
En git podemos agregar ramas que no necesariamente sus commits van a ser enviados a Master.
Podriamos tener una rama llamada Development donde tomamos una version especifica del Master para poder trabajar sobre ella en un proyecto que aun no sabemos si lo vamos a unir al proyecto final.

Al momento de unir nuestra rama Development con la rama Master debemos de hacer un MERGE que crea una nueva version final uniendo todo.

NOTA Puede haber problemas de compatibilidad entre una rama y la otra.

3 ramas a considerar en los proyectos:

  • Master
  • Development (Desarrollo)
  • Hotfixing (bugfixing)

Buena explicación.

Me encanta el formato de explicación, los detalles y la forma de expresarse John Freddy Vega

Freddy tienes un don para explicar las cosas, Excelente! 😄

Es una herramienta obligatoria entonces de aprender

Git-merge Une dos o más historiales de desarrollo.

GIT FLOW ❤️

Muy buena explicación, aunque Freddier debe mejorar su técnica de dibujo jaja

Braches y Git Flow 🚀

¿Qué es un Branch (rama) y cómo funciona un Merge en Git?
Git es una base de datos muy precisa con todos los cambios y crecimiento que ha tenido nuestro proyecto. Los commits son la única forma de tener un registro de los cambios. Pero las ramas amplifican mucho más el potencial de Git.

Todos los commits se aplican sobre una rama. Por defecto, siempre empezamos en la rama master (pero puedes cambiarle el nombre si no te gusta) y creamos nuevas ramas, a partir de esta, para crear flujos de trabajo independientes.

Crear una nueva rama se trata de copiar un commit (de cualquier rama), pasarlo a otro lado (a otra rama) y continuar el trabajo de una parte específica de nuestro proyecto sin afectar el flujo de trabajo principal (que continúa en la rama master o la rama principal).

Los equipos de desarrollo tienen un estándar: Todo lo que esté en la rama master va a producción, las nuevas features, características y experimentos van en una rama “development” (para unirse a master cuando estén definitivamente listas) y los issues o errores se solucionan en una rama “hotfix” para unirse a master tan pronto como sea posible.

Crear una nueva rama lo conocemos como Checkout. Unir dos ramas lo conocemos como Merge.

Podemos crear todas las ramas y commits que queramos. De hecho, podemos aprovechar el registro de cambios de Git para crear ramas, traer versiones viejas del código, arreglarlas y combinarlas de nuevo para mejorar el proyecto.

Solo ten en cuenta que combinar estas ramas (sí, hacer “merge”) puede generar conflictos. Algunos archivos pueden ser diferentes en ambas ramas. Git es muy inteligente y puede intentar unir estos cambios automáticamente, pero no siempre funciona. En algunos casos, somos nosotros los que debemos resolver estos conflictos “a mano”.

Les dejo un tutorial de Atlassian en la que profundizan sobre los distintos tipos de flujo que podemos usar con Git:

https://www.atlassian.com/es/git/tutorials/comparing-workflows

Como recomendación, es importante que nunca se trabaje o se hagan cambios directamente sobre la rama master, en la rama master solo debería existir la versión mas estable de nuestro proyecto o (lo que está en producción). Mientras estemos agregando nuevas caracteristicas, todo debería estar en una rama de desarrollo o development

Hola compañeros, para los que se encuentren realizando este curso para despues de mediados de octubre del 2020, les cuento que debido a una actualización de Git, la rama “Master” ha cambiado su nombre por defecto a “Main”. Les aviso para que no se lleven sorpresas creando repositorios mas adelante. Un saludo y #NuncaParenDeAprender ❤️

📝 Las ramas nos permiten llevar un mejor control del código. Crea un nuevo camino de cara a la evolución del código, en paralelo a otras ramas que se puedan generar.

Nombres recomendados para ramas:

Experimentos ratos => development
Bugs => hotfix

Mis notas de la clase

Apuntes del curso 👉🏻 acá
Apuntes de la clase 👇🏻

Resumen de palabras para trabajar en equipo:

Branch Master: es la rama principal, ““la primera””.
Branch: (rama) son todasa las ramas que tienes.
Merge: (unir) es unir un commit con otro commint, pueden ser de diferentes versiones.
Cheout: (revisar) es crear una rama nueva.
Hotfix: (revisión) es revisar lo mas rapido posible porque hay que unirla a un Brach.

Espero les sea util: 😎💚💚

Leer también el libro que recomienda al principio me está ayudando mucho, así se puede profundizar más.

Esto se podría explicar bien con la idea de los multuniversos de Marvel.

Ramas:

  • Herramienta de git para tener diferentes flujos de trabajo y luego fucionarlos.
  • Las ramas se crean copiando un commit anterior (checkout) para luego generar un nuevo flujo sobre este.
  • Fucionar dos ramas (merge) puede generar conflictos: diferencias entre ambos archivos.
  • Algunas ramas usuales son:
    hotfix: rama de solucion de errores
    development: rama de experimentos

Commit

Un commit es un cambio rastreable (de 1 o varios archivos), es confirmar un conjunto de cambios provisionales de forma permanente y tenemos el superpoder de ponerle nombre a este cambio.

La historia de tu desarrollo se van guardando mediante commits, ya que cada cambio confirmado tiene modificaciones importantes hasta llegar al cambio actual.

Para hacer un commit, es muy sencillo, tenemos que tener agregado en el staging (git add -A) y usar el comando commit

Git commit -m 'commit'

Si trabajamos en algo experimental o que no queremos que sea parte del flujo principal, podemos hacer una nueva rama (branch), recordemos que la rama principal suela llamarse master, por lo tanto ésta branch nueva tendrá su propia historia (posterior al punto donde se creó).

Para crear una rama nueva con la información de la rama actual usamos el comando

git checkout -b nombre-del-branch

Si los cambios que realizaste en tu rama nueva son un avance en el código, puedes fusionarlo a la rama master (o a otra), para ésto tienes que cambiarte a master y hacer el comando es merge

git checkout master # nos cambiamos a la rama master
git merge rama-nueva # Fusionamos los cambios de la 'rama-nueva' en master

Es excelente la forma en la que se explica este tema, en realidad en una empresa las ramas (la mayoría de las veces) se llaman así como menciona Freddy). Por acá dejó links de la documentación oficial de Git donde se hablan sobre estos temas.
¿Qué es una rama?
Procedimientos básicos para ramificar y fusionar

Llevo un tiempo utilizando Git en distintos proyectos, pero en ningún momento me había detenido a estructurar su funcionamiento, definitivamente es impresionante!

**Ramas: **
Master: Rama principal de nuestro repositorio (Donde estan las versiones 1, 2, 3… actual).

Nombres comunes para una rama en la que arreglamos fallos: bugfixing/hotfix.

**Ramas: **
Master: Rama principal de nuestro repositorio (Donde estan las versiones 1, 2, 3… actual).

Nombres comunes para una rama en la que arreglamos fallos: bugfixing/hotfix.

Cuando queremos fusionar los cambios de una rama con la rama master (u otra rama):

git merge [nombreDeLaRama]

Como recomendación personal, revisen periódicamente sus repositorios, me he topado con repositorios internos donde tenemos mas de 60 ramas de las cuales solo el 5 o 10% son útiles, el resto son funcionalidades que se abandonaron o que se rechazaron,

Puedes practicar el uso de las ramas haciendo modificaciones a los proyectos de los cursos, esto te servirá de práctica. Al final puedes tener tantas variantes como ramas en tu repositorio, tu decidirás si quieres hacerle merge a éstas o dejarlas tal cual.

Desde octubre del 2020 ahora la rama master tiene como nuevo nombre main.

  • Lo único que cambia es el nombre y tener en cuenta el nombre en los comandos
  • Dadle ❤️ para que todos se enteren y no se vayan a perder 😃
  • Suerte 😄

En Learn Git Branching es posible practicar y aprender más sobre ramificación, chéquenlo… 😛

Si en el proceso de “Merge” tengo 2 cambios diferentes en la misma línea entre las ramas como se elige que cambio dejar?

Es posible hacer un merge entre más de 2 ramas?

git merge => Mezclar Ramas (En escencia)

Pasar de manejar solo una rama(Master) a manejar quizá 3 o más(Development, Hotfix, etc) esta de locos!!!
Con cada clase el curso se pone mas emocionante… 😉😉😉

WOW!! Git es un lio

😊

La convención de llamar a “Master” a la rama principal del proyecto cambió hace poco, ahora se le llama “Main”

Los hotfix o cambios en caliente te realizan una copia de la rama de producción (comúnmente la rama es master) y a partir de ahí realizar los cambios, al finalizar tus cambios, finalizas el hotfix y los cambios se mezclan en la rama de producción y en la rama de desarrollo (master, develop) de esta manera se garantiza que se corrige el problema en producción y hacia el futuro dado que en algún momento lo que este en la rama de desarrollo saldrá a producción.
Te invito a revisar que son los flujos de trabajo en git:

git flow init -f

Donde tendrás que definir cual es la rama que tienes para producción cual para desarrollo, cual para nuevas características, cual para los cambios en calientes, etc.
https://readthedocs.org/projects/git-flow/downloads/pdf/latest/
https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow

Tip: Podemos usar git bash directamente desde visual studio code

Merge

Realice esto según lo que entendí.
Pd: Acepto correcciones.

Master actualmente ya no es ni debe ser Master debido a los términos raciales que se utilizaban, y desde el #BlackLivesMatter la rama Master cambió a ser la rama Main.

Cambio de Master a Main

• El HEAD es un putero que señala a la versión con la que se está trabajando.
• Generalmente se trabajan en ramas Development para desarrollo y experimentos, hotfix (bugfigting) para arreglos en caliente.
• Al hacer merge, pueden llegar a existir conflictos los cuales se tienen que arreglar.

11. ¿Qué es un Branch (rama) y cómo funciona un Merge en Git?


🤗

Definitivamente es muy importante practicar, practicar y practicar. Como dice Freddy, solo con ver el video no es suficiente.

Buena, creo que al fin la entendi! se me habia hecho un poco dificil, pero ya esta!

git es amor

interesante me queda la duda si dos ramas modifican una misma parte, como se unirian??

Este flow de git me ha ayudado mucho a como moverme entre ramas. Este tema ha sido de muchas discuciones; ya que, es aquí donde puedes dañar tu codigo.
https://nvie.com/posts/a-successful-git-branching-model/

Cásate conmigo Freddy. ¡Excelente explicación!

Muy bien explicado!

Si freddy diera todos los cursos…

conflicto: Cuando al hacer un merge los cambios de una rama rompan los cambios de la otra.

bug = bəɡ 😉

creo q ya no se usa rama master , si no rama main

https://www.youtube.com/watch?v=VdGzPZ31ts8

ME GUSTA COMO EXPLICA FREDDY PERO POR ACA DEJO UN VIDEO DONDE HAY UNA EXPLICACION MUY BUENA DE TODO LO VISTO QUE ME PARECE IMPORTANTE

Ósea, que usted me esta tratando de decir que los multiversos en Git son posibles? xdd

El merge no debería entenderse en el sentido de unir si no en el de fusionar o de mezclar. No se une la rama A con la rama B. Se fusionan los cambios de la rama A en la rama B.

¿cual es la diferencia entre checkaut y commint?

Freddy es un excelente profesor _

Mi aporte para esta clase:

Las ramas o branch son la representación de las modificaciones o commits que hacemos en nuestro proyecto.
Hay una rama principal llamada Master, que contiene la parte principal del proyecto y luego está
Developer: una rama para hacer desarrollo, modificaciones sin afectar Master.
Luego Hotfix, que sirve para intervenir de manera paralela a Master. Y ya que se logra realizar el arreglo a la falla de Master, podemos unir esta reparación a Master por medio de merge, o unir ramas en una version de commit determinada.

Muy buena clase

Me encantó, definitivamente si no es porque tengo más responsabilidades, lo vería de corrido.

merge fusionar ramas ok