BIBLIA DE GIT Y GITHUB

Control de versiones y trabajo en equipo

El control de versiones se refiere al proceso de guardar diferentes archivos o «versiones» a lo
largo de las diferentes etapas de un proyecto. Esto permite a los desarrolladores hacer un
seguimiento de lo que se ha hecho y volver a una fase anterior si deciden que quieren revertir
algunos de los cambios que han hecho.

GIT y Github NO SON LO MISMO

GIT es una herramienta de control de versiones que se instala en computadoras y nos permite
guardar el progreso de nuestros proyectos. GIT trabaja sobre repositorios, es decir, siempre que
estemos usando GIT lo vamos a hacer sobre un repositorio creado por nosotros o por terceros en
el caso que estemos trabajando en equipo.
Para centralizar el acceso a estos repositorios, los mismos se suben a plataformas que están en la
nube para que todo aquel que tenga acceso pueda descargar el repositorio, trabajar en él y subir
sus cambios a la nube para que el resto del equipo pueda verlo y descargarlo.

Github es una de las plataformas más usadas que nos permiten alojar repositorios GIT en la nube,
brindando una serie de funcionalidades que nos facilita el trabajo en equipo, ver el trabajo de los
demás y juntar todo el trabajo bajo una misma versión.

TRABAJO EN EQUIPO
En el día a día del trabajo con Git una de las cosas útiles que podemos hacer es trabajar con
branch. Las branches (o ramas) son caminos que puede tomar el desarrollo de un software, algo
que ocurre naturalmente para resolver problemas o crear nuevas funcionalidades. En la práctica
permiten que nuestro proyecto pueda tener diversos estados y que los desarrolladores sean
capaces de pasar de uno a otro de una manera ágil.

Por ejemplo, si estás trabajando en un repositorio y tenes que implementar una nueva
funcionalidad, podes crear una nueva branch en donde realizar el trabajo. Esto permite mantener
todo el desarrollo en una branch separada del código principal, evitando que el resto del equipo
tenga que trabajar sobre lo que vos estás trabajando, que aún no está finalizado. En simples
palabras, te permite tener diferentes versiones de un mismo proyecto, las cuales se pueden
fusionar o descartar sin afectar el código principal.

Las branches en Git te permiten, ejecutando un sencillo comando, poner de nuevo el proyecto en
el estado original que tenías, antes de empezar a hacer esos cambios que no has terminado.

Llegará un momento en el que, quizás, aquellos cambios experimentales los quieras juntar a la
branch principal, entonces harás un proceso de fusión entre la branch experimental y la branch
principal. Esta operación se conoce como merge en Git.

1
 GITHUB
Como explicamos anteriormente, Github es una plataforma online que nos permite alojar un
repositorio GIT en la nube. No es la única plataforma que hace esto, pero si es una de las más
utilizadas actualmente.

Dentro de la plataforma se pueden ver los repositorios remotos y en cada uno se puede ver
información como los commits realizados, la branches creadas, los colaboradores (personas que
realizan o realizaron cambios en el código), etc.

Al momento de trabajar en equipos, debemos trabajar con branches para poder mantener
separado el progreso de cada colaborador o mejor dicho de cada developer. De esta manera,
podemos ver los diferentes estados del repositorio separados por branches las cuales tienen
commits, permitiendo tener un historial de todos los cambios realizados por cada colaborador.

Llegado el momento, cuando el desarrollo de una banch está completo por el developer, esta se
debe fusionar a la branch principal del repositorio para que los cambios realizados sean parte del
código principal. Existen muchas formas de fusionar branches, en Github vamos a usar la
funcionalidad llamada “Pull Request”, la cual nos va a crear una solicitud de fusión de una branch
a otra. Por ejemplo: si queremos fusionar la branch A a la branch B, en la sección de “Pull
Requests” de Github vamos a ver una solicitud creada para dicha fusión.

En una Pull Request se pueden ver muchas cosas: el autor de la misma, la parte del código que se
está modificando, cuál es la branch que se quiere fusionar y a qué branch se quiere fusionar, entre
otros. Las Pull Request también permiten a los colaboradores dejar comentarios en caso de que
no estén de acuerdo con cierta modificación. El autor de la branch puede realizar los cambios,
subirlos a la branch remota y luego puede indicar en la PR que esos cambios ya fueron realizados,
reactivando el proceso de revisión de la PR. Dependiendo la configuración de cada repositorio, es
muy común que para poder fusionar una Pull Request sea necesario que otros colaboradores la
aprueben. Luego de tener las aprobaciones necesarias, se puede realizar la fusión, la cual
llamaremos "merge".

Una PR puede no ser aprobada en el caso que los cambios realizados en una branch no convenza
al resto del equipo o simplemente se quiera descartar lo realizado en la branch. En este caso se
puede rechazar la PR, cerrando la misma y dejando sin efecto el merge. La branch original seguirá
existiendo, a menos que también sea eliminada de la lista de branches en el repositorio remoto.

2
 ¿QUÉ SON LOS CONFLICTOS?
Cuando trabajamos en equipo usando branches, a veces, se puede dar el caso de que varios
desarrolladores intenten editar el mismo contenido. Si el desarrollador A intenta editar código que
el desarrollador B está editando, podría producirse un conflicto. Para evitar que se produzcan
conflictos los desarrolladores trabajan en branches aisladas independientes.

La fusión y los conflictos son una parte común de la experiencia de Git. La mayor parte del tiempo
Git se las ingeniará para integrar automáticamente los nuevos cambios.

Normalmente los conflictos surgen cuando dos personas han cambiado las mismas líneas de un
archivo o si un desarrollador ha eliminado un archivo mientras otro lo estaba modificando. En
estos casos, Git no puede determinar automáticamente qué es correcto. Los conflictos sólo
afectan al desarrollador que realiza la fusión, el resto del equipo no se entera del conflicto. Git
marcará el archivo como que tiene un conflicto y detendrá el proceso de fusión. Entonces el
desarrollador es el responsable de resolver el conflicto.

¿CÓMO RESOLVER CONFLICTOS?

1. Se posicionan dentro de la terminal en la rama que tiene conflictos
git checkout nombre-rama

2. Actualizan la referencia del repo remoto.

git fetch
No es necesario que hagan git pull, con git fetch ya están actualizando la información del repo
remoto al repo local

3. Hacen un merge de la rama master en su rama (git merge origin/master)

git merge origin/master
Importante que pongan “origin/master” y no hacer “origin master”

4. En Visual Code, van a la pestaña de “Source Control” y resuelven los conflictos. Recuerden
guardar todos los archivos en donde resolvieron conflictos.

5. Una vez resueltos todos los conflictos agregan los cambios (asegurarse bien de eso, que no
queden conflictos sin resolver).
git add .

6. Guardan todos los cambios agregados en un commit, solo tienen que ejecutar “git commit”
sin nombre ni nada extra, con este comando automáticamente se crea el commit merge.
git commit

7. Una vez hecho el commit, hacen un push a su rama con los nuevos cambios.
git push origin nombre-rama

3
 COMANDOS GIT MAS USADOS

git status
Muestra la lista de los archivos que se han cambiado (en rojo) junto con los archivos que están por
ser preparados o confirmados (en verde).
git status

git add
Se usa para agregar a los archivos que luego queramos agregar a un commit. Seguido de “git add
” se debe indicar cual o cuales archivos queremos agregar, por ejemplo “git add index.js”. Si
queremos agregar todos los cambios realizados o archivos nuevos, podemos usar “git add .”
git add archivo.js

git commit
Nos permite crear un commit con todos los cambios agregados previamente (archivos que
aparecen en verde cuando ejecutamos “git status”, los rojos no se agregan al commit). Si no hay
archivos agregados previamente, no se creará ningún commit. Para agregarle un mensaje
(nombre) al commit se debe agregar “-m” seguido del nombre escrito entre comillas (las comillas
se usan siempre que el texto escrito como nombre tenga espacios en blanco, de lo contrario las
comillas no son necesarias).
git commit -m “Nombre del commit”

git checkout
Este comando sirve para varias cosas, en este caso vamos a explicar como usarlo para descartar
cambios realizados que no fueron agregados ni tampoco guardados en un commit, es decir, para
descartar todos los cambios que se muestran en rojo cuando ejecutamos “git status”. Vale aclarar
que solo descarta los cambios hechos en archivos, no descarta archivos creados, es decir, si el
único cambio que hice en el repositorio fue crear un archivo, este comando no sirve para eliminar
ese archivo, solo sirve para descartar los cambios hechos sobre archivos.
Al igual que el comando “git add” se puede indicar sobre cuál o cuales archivos queremos
descartar los cambios, por ejemplo “git checkout archivo.js” o podemos descartar todos los
cambios realizados con el comando “git checkout .” (punto).
git checkout archivo.js

4
 git push
Se usa para subir los cambios realizados desde nuestro repositorio local al repositorio remoto
alojado en nuestro caso en Github. Solo se van a subir los cambios que se hayan guardado bajo
un commit, aquellos cambios que no estén bajo un commit no se suben, es decir, los archivos que
aparezcan en verde o rojo cuando ejecutamos “git status”. Al momento de subir los cambios con
este comando se debe indicar a qué branch se quieren subir los cambios, para eso se debe poner
“origin nombre-branch”, la palabra “origin” hace referencia al repositorio remoto alojado en la
nube, nombre-branch es el nombre de la branch a la cual queremos subir los cambios.
git push origin nombre-branch

git pull
Este comando se usa para actualizar el repositorio local en relación al repositorio remoto. Es decir,
si estamos posicionados en una branch en el repositorio local y dicha branch fue actualizada por
otra persona y esos cambios fueron subidos al repositorio remoto (Github), se pueden descargar
esos cambios al repositorio local ejecutando “git pull”. Al igual que el comando “git push”, se debe
indicar desde cual branch queremos actualizar.
git pull origin ejemplo-branch

git checkout -b <branch>

Como dijimos anteriormente, el comando checkout sirve para varias cosas. En este caso se usa
para crear una nueva branch localmente. Para eso, es necesario agregar la opción “-b” para indicar
que se está creando una nueva branch, seguido a eso se debe poner el nombre de la nueva
branch, por ejemplo “git checkout -b nueva-branch”. Los nombres de branches no pueden tener
espacios en blanco. Vale aclarar que las branches creadas localmente no se crean
automáticamente en el repositorio remoto (Github), es decir que al crear una branch desde la
terminal no se va a ver en Github hasta que no se subas los cambios (usando “git push”).
git checkout -b nombre-nueva-branch

git checkout <branch>

Usando este mismo comando pero solo indicando el nombre de una branch existente, nos permite
movernos de una branch a otra. Si la branch a la cual nos queremos mover no existe localmente
pero si en el repositorio remoto, la branch se descarga automáticamente.
git checkout nombre-branch

5
 git branch
Este comando tiene varios usos, todos relacionados al manejo de branches. En este caso, para ver
la lista de branches que tenemos descargadas en el repositorio local, ejecutamos “git branch” sin
ninguna otra opción. Solo veremos listadas las branches locales, eso no significa que podamos
movernos a una branch que esté en el repositorio remoto (Github).
git branch

git branch -D
Para borrar una branch localmente, usamos el comando “git branch” agregando la opción “-D” con
la D en mayúsculas seguido del nombre de la branch la cual queremos eliminar. Esto solo borra la
branch del repositorio local, es decir que solo lo borra en la computadora, la branch sigue
existiendo en el repositorio remoto (Github). Lo mismo sucede a la inversa, si eliminamos una
branch desde Github, no se borrara en los repositorios locales de las personas que hayan clonado
el repositorio. En el caso que tengamos commits en la branch que no se hayan subido al
repositorio remoto, en el momento que se elimina la branch, se pierden esos commits. Es
importante aclarar que deben estar parados en una branch diferente a la que quiere eliminar. Es
decir, si quieren borrar la branch “nombre-branch”, deberían cambiarse a otra branch, ejemplo:
“main” y ejecutar el siguiente comando para que se elimine correctamente. Si se ejecuta el
comando, estando parados en la misma branch a borrar, ésta no será eliminada.
git branch -D nombre-branch

git branch -a
Nos permite listar todas las branches existentes, tanto en el repositorio local como en el
repositorio remoto (Github).
git branch -a

git fetch
Es el comando que le dice al repositorio local que recupere la última información de los metadatos
del original (aunque no hace ninguna transferencia de archivos. Es más bien como comprobar si
hay algún cambio disponible).
El repositorio local nunca se actualiza automáticamente con el repositorio remoto, todo se
hace manualmente con los diferentes comando antes mencionados, por ejemplo, cuando creamos
una branch en el repositorio local no se crea en el repositorio remoto hasta que no se haga “git
push” de los cambios. Lo mismo funciona con los metadatos del repositorio remoto, para que el
repositorio local sepa si hay cambios realizados en el repositorio remoto, también se debe hacer
manualmente, y para eso se utiliza “git fetch”.
git fetch

6
 Fuente:

- https://www.atlassian.com/es/git/tutorials/using-branches/merge-conflicts
- https://desarrolloweb.com/articulos/trabajar-ramas-git.html
- https://www.freecodecamp.org/news/git-fetch-vs-pull/
- Equipo de desarrollo de Radium Rocket