Clase 9. Material Complementario GIT
Clase 9. Material Complementario GIT
Clase 9. Material Complementario GIT
CLASE 9
GIT
¿QUÉ ES GIT?
Existen muchos sistemas de control de Versiones. Git es uno de ellos y el más aceptado
por la comunidad de desarrolladores.
VCS Local
Es un VCS que vive en tu computadora. Sólo allí. Si nuestra computadora se rompe o
destruye ya no podremos obtener nuestros archivos por razones obvias. Depende
completamente de donde se esté manejando, en este caso, nuestra computadora.
Esta configuración ofrece muchas ventajas, especialmente frente a VCSs locales. Por
ejemplo, todo el mundo puede saber (hasta cierto punto) en qué están trabajando los
otros colaboradores del proyecto. Los administradores tienen control detallado de qué
puede hacer cada uno; y es mucho más fácil administrar un CVCS que tener que lidiar
con bases de datos locales en cada cliente.
Sin embargo, esta configuración también tiene serias desventajas. La más obvia es el
punto único de fallo que representa el servidor centralizado. Si ese servidor se cae
durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios
versionados de aquello en que están trabajando. Si el disco duro en el que se encuentra
la base de datos central se corrompe, y no se han llevado copias de seguridad
VCS Distribuidos
Es aquí donde entran los sistemas de control de versiones distribuidos. En un DVCS
(como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última
instantánea de los archivos: replican completamente el repositorio. Así, si un servidor
muere, y estos sistemas estaban colaborando a través de él, cualquiera de los
repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que
se descarga una instantánea, en realidad se hace una copia de seguridad completa de
Es más, muchos de estos sistemas se las arreglan bastante bien teniendo varios
repositorios con los que trabajar, por lo que puedes colaborar con distintos grupos de
gente simultáneamente dentro del mismo proyecto. Esto te permite establecer varios
flujos de trabajo que no son posibles en sistemas centralizados, como pueden ser los
modelos jerárquicos.
● Velocidad
● Diseño sencillo
● Fuerte apoyo al desarrollo no lineal (miles de ramas paralelas)
● Completamente distribuido
● Capaz de manejar grandes proyectos (como el núcleo de Linux) de manera
eficiente (velocidad y tamaño de los datos)
Desde su nacimiento en 2005, Git ha evolucionado y madurado para ser fácil de usar y
aún conservar estas cualidades iniciales. Es tremendamente rápido, muy eficiente con
grandes proyectos, y tiene un increíble sistema de ramificación (branching) para
desarrollo no lineal
Fuente(https://git-scm.com/book/es/v1/Empezando-Una-breve-historia-de-Git)
Esto nos lleva a las tres secciones principales de un proyecto de Git: el directorio de Git
(Git directory), el directorio de trabajo (working directory), y el área de preparación
(staging area).
El flujo es: Creo los archivos en la carpeta del proyecto (Working Directory); luego indico
¿QUÉ ES GITHUB?
Git es uno de los sistemas de control de versiones más populares entre los
desarrolladores. Y parte culpa de su popularidad la tiene GitHub, un excelente servicio
de alojamiento de repositorios de software con este sistema, que lejos de quedarse en
esta funcionalidad, ofrece hoy en día un conjunto de características muy útiles para el
trabajo en equipo.
No en vano, es el servicio elegido por proyectos de software libre como jQuery, reddit,
Sparkle, curl, Ruby on Rails, node.js, ClickToFlash, Erlang/OTP, CakePHP, Redis, y otros
muchos. Además, algunas de las grandes empresas de Internet, como Facebook, alojan
ahí sus desarrollos públicos, tales como el SDK, librerías, ejemplos, etc.
Para resumir:
GitHub: Plataforma de proyectos Git. Es popularmente conocida como la red social de
desarrolladores, hay proyectos muy interesantes allí.
Otras plataformas pueden ser BitBucket o GitLab
2- Ahora debes ejecutar el archivo descargado, y elige la carpeta donde ubicar los
archivos de Git
3- Asegúrate de tener seleccionado git bash que es la herramienta principal con la que
trabajaremos y con esto se terminará la instalación
Tu identidad
Lo primero que deberías hacer cuando instalas Git es establecer tu nombre de usuario y
dirección de correo electrónico. Esto es importante porque las confirmaciones de
cambios (commits) en Git usan esta información, y es introducida de manera inmutable
en los commits que envías:
john@MyShopSolutions MINGW64 /c
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
Comprobando tu configuración
Si quieres comprobar tu configuración, puedes usar el comando git config --list para
listar todas las propiedades que Git ha configurado:
john@MyShopSolutions MINGW64 /c
$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
También puedes comprobar qué valor cree Git que tiene una clave específica ejecutando
john@MyShopSolutions MINGW64 /c
$ git config user.name
John Doe
john@MyShopSolutions MINGW64 /c
$ git help config
$ git config --help
$ man git-config
Resumen
Deberías tener un conocimiento básico de qué es Git y en qué se diferencia del CVCS
que puedes haber estado utilizando. También deberías tener funcionando en tu sistema
una versión de Git configurada con tu identidad. Es el momento de aprender algunos
fundamentos de Git.
Luego vino Windows y trajo consigo las ventanas, los iconos y las carpetas. Al principio
dependía de DOS, pero más tarde se independizó y relegó la línea de comandos a lo que
ahora conocemos como símbolo del sistema (command prompt o CMD) o consola de
Windows.
Para abrir la línea de comandos de Windows o símbolo del sistema tan sólo tenemos
que ir a Inicio > Ejecutar o Buscar > CMD.exe y se abrirá una pequeña ventana que nos
recordará al antiguo MS-DOS.
Para abrir la Terminal de Mac OS haz clic en el icono "Finder" situado en el Dock, luego
seleccione "Aplicaciones > Utilidades" Finalmente dale doble clic al icono "Terminal"
Hay que tener varias cosas en cuenta:
● No diferencia entre mayúsculas y minúsculas
● Al escribir un nombre de archivo o carpeta con espacios conviene escribirlo
entrecomillado
● Los nombres pueden ser de hasta 255 caracteres y con extensiones de hasta 3
caracteres* Si eliminas un archivo desde CMD no va a la Papelera.
CREANDO REPOSITORIOS
Git status
Ya hemos visto cómo inicializar un repositorio localmente utilizando git init. Ahora nos
toca crear los archivos que vamos a usar en este repositorio.
Luego utilizando el comando git status vamos a poder ver el estatus de los archivos que
tenemos localmente, o sea en nuestro Working Directory
Lo que aparezca en rojo es lo que se ha modificado y hay que pasarlo a nuestro Staging
Area (el limbo)
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html
Git add
Para agregar el o los archivos al Staging Area vamos a usar el comando add lo cual
podemos verificar si funciono nuevamente con el git status
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
Git commit
Una vez que nuestros archivos están en el Staging Area debemos pasarlos a nuestro
repositorio local y para eso debemos usar el git commit que es el comando que nos va a
permitir comprometer nuestros archivos.
Git log
Por medio de este comando veremos la historia de nuestro proyecto.
Utilizando git log podrás ver los codigos hexadecimales que crea Sha-1, el autor y la
fecha en la que se envió ese commit.
La documentación de git log es super extensa y puedes revisar completamente desde
aquí
https://git-scm.com/book/es/v1/Fundamentos-de-Git-Viendo-el-hist%C3%B3rico-de-
confirmaciones
nuevo archivo
Git diff
Para hacer un control de la revisión de los cambios podemos usar el git diff
Si queremos saber cuales son los cambios entre un commit y otro diferente, solo
debemos hacer una comparación entre un commit y otro usando el código proveniente
desde el Sha-1
En verde nos marcan las líneas nuevas y en rojo las líneas eliminadas de nuestro
documento
Extras
Por supuesto existen mucho más comandos, puedes encontrar la información completa
desde la página oficial de Git y la documentación que nos ofrece.
https://git-scm.com/book/es/v1/
O ver el listado de comandos basicos para Git:
https://www.hostinger.es/tutoriales/comandos-de-git
( Fuente: http://rogerdudler.github.io/git-guide/ )
Git branch
Este comando lo usaremos para crear una nueva rama o un nuevo branch.
En el ejemplo vamos a crear una nueva rama para los archivos de la nueva versión
responsive de nuestro proyecto.
Para borrar una rama usamos el comando git branch -D [nombre de la rama]
Volvemos a crear una nueva rama y esta vez vamos a renombrarla con el comando git
branch -m [nombre de la rama] [nombre nuevo de la rama]
john@MyShopSolutions MINGW64 /c/git/nuevo_repo (master)
$ git branch features
$ git branch -m features f-responsive
Ahora la rama features pasó a llamarse f-responsive
Git checkout
Ahora vamos a ver con que comando podemos movernos entre nuestras diferentes
ramas y posicionarnos en una como en otra para empezar a trabajar sobre ellas.
Luego con el comando checkout nos posicionamos sobre el commit que seleccionamos
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
Git merge
Habiendo trabajado en diferentes ramas deberíamos de mezclarlas. Lo primero que
debemos hacer para mezclar ramas es pararnos sobre la rama master y desde allí usar
el comando git merge [rama a fundir con el master]
Con el comando git log --oneline --graph podremos ver la bifurcaciones de nuestro
proyecto con sus respectivas y diferentes ramas y como se fueron fusionando con
nuestra rama master.
● Git-gui
● GitHub Desktop
● GitKraken
● SmartGit
● SourceTree