Sobre mí

Hola !

Mi nombre es Filiberto, lo sé es raro pero tu llámame "Fili", tengo 18 años, vivo en México, hace un año que soy parte de la comunidad Platzi. Me considero una persona emprendedora, creativa, con ganas de siempre aprender más. Te doy la bienvenida a esta presentación y espero que sea de tu agrado.

Nota: Siempre mantente al tanto de la esquina inferior derecha, ya que pueden haber temas con contenido más abajo.

Sígueme y seré muy feliz

Antes de empezar

Entra al curso

Esta presentación esta pensada y hecha sólo para los estudiantes del curso de Git & Github de mejorandola, así que si no eres parte del curso ¿qué esperas?.

Dudas y Comentarios

Si tienes alguna duda, comentario, error, quieres sugerir algo, quieres algún cambio, o incluso si ves alguna falta de ortografía, manda un mensaje através de las redes sociales ó manda un tweet con el hashtag #filigit, responderé lo más pronto que pueda.

Control de versiones

Qué es?

Es la gestión de diversos cambios que se realizan sobre un elemento, registran y guardan cada modificación del proyecto, de igual forma nos solucionan tres problemas del pasado:

• Proyectos difíciles de gestionar y liderar.
• Riesgos a sobrescribir con mi código al avance formal del equipo.
• La centralización y poca probabilidad de trabajar remotamente.

Arquitectura del árbol

Working Area

Qué es?

Aquí es donde editamos y tabajamos con nuestros proyectos, es cuando decidimos abrir el editor de código, preparar una buena taza de café y empezar a hacer magia.

Staging Area

Qué es?

Aquí es donde escogemos que archivos están listos para el siguiente commit, de igual manera decidimos que archivos no lo están y no pueden continuar por el momento.

Repository

Qué es?

Aquí es el registro de todo nuestro proyecto, ese proyecto por el cual pasaste dos noches sin dormir y tomaste diez tazas de café, pero que sin duda te deja una gran satisfacción al terminar.

Configuración

git --version

Qué es?

Después de haber instalado git, tenemos que comprobar si todo está bien, así que solo basta con escribir en la consola git --version y esto nos dará como resultado, la versión actual que tenemos en nuestro computador.

git config --global user.name "Tu nombre"

Qué es?

Al saber que tenemos git y que todo va perfecto, ahora tenemos que definir nuestro nombre de usuario, para eso sirve este comando y es como git sabe quienes somos.

git config --global user.email "Tu correo"

Qué es?

Git ya sabe nuestro nombre, pero aún no sabe nuestro correo electrónico y esto es algo necesario para git, con un simple comando le decimos nuestro correo.

git config --global user.ui true"

Qué es?

Este simple comando lo que hace es darnos una interfaz de colores, te lo recomiendo para que sea más fácil diferenciar algunas cosas de otras.

git config --global --list"

Qué es?

Por último tenemos este comando que nos dice nuestras configuraciones a nivel global, todo lo que hicimos antes aquí no los muestra.

Extra

Se usa --global para que el cambio o configuración que hacemos sea a nivel global y afecte a todos los usuarios por igual.

Si queremos cambiar el nombre de usuario o correo sólo tenemos que volver a usar el mismo comando pero con el nuevo nombre:

• git config --global use.name "Nuevo nombre"
• git config --global use.email "Nuevo correo"

70% Git

git help

Qué es?

Es un comando que se utiliza para saber como funciona cada instrucción de git, al igual que da una breve explicacíon de dicha instrucción.

git --help comando.

git init

Qué es?

Con esté comando le decimos a git que empiece a monitorear todos los cambios que haga en mi carpeta de trabajo, es el Nivel 1 de nuestro proyecto, es el inicio de una fantástica aventura.

Si no inicias con git init nos dirá que no hay un repositorio de git.

git status

Qué es?

Nos muestra el estado en el que se encuentra nuestro proyecto:

• Que cambios hay.
• Que cambios viejos borraste.
• Que es lo que sigue.

git add

Qué es?

Con este comando decidimos que archivos van a convertirse en commit y que archivos aún no están listos.

Agregamos todos los archivos.

git add -A

Agregamos solo el archivo index.html o el nombre del archivo que usemos.

git add index.html

git commit -m "mensaje"

Qué es?

Aquí ya estamos en la ultima parte del esquema de árbol y es hacer un commit como tal.

Ya que hicimos código y decidimos que archivos están listos, solo queda guardar lo que hicimos en un commit es decir el trabajo de hoy está hecho.

git commit -m "hoy pase de estar en ssj3 a ssj4"

git log

Qué es?

Nos dice como está el repositorio a nivel de commits (Cuantos commits tenemos en el repositorio), quien las hizo, cuando las hizo y básicamente todo.

git log > commits.txt

Qué es?

Es exactamente lo mismo que git log solo que este nos genera un .txt con los commits en la raíz del proyecto.

git checkout

Qué es?

Con este comando viajamos a travez del tiempo, y podemos ir a cualquier commit que tengamos atrás, esto sin afectar a los que hay enfrente.

Si hacemos un cambio a algún proyecto que tienes atrás, crearás dos mundos paralelos

git checkout commit

git checkout master

Master -> rama principal

git reset

Qué es?

Este comando es súper poderoso y ten cuidado con usarlo, hace lo mismo que git checkout a diferencia que arrasa con todos los commits que tiene enfrente.

Tiene tres tipos de ejeción:

git reset --soft

Es un reset tranquilo, tu Working Area lo deja, no se mete con tú código.

git reset --mixed

Este reset es raro y muy poco usado, borra tu Staging Area sin tocar tu Working Area

git reset --hard

Este comando lo que dice es ¡Hey quiero borrar todo! y en efecto eso es lo que hace, inluyendo tu código.

Ramas

Qué es?

Una rama es una línea del tiempo, en la historia de nuestro repositorio, funciona para crear features, arreglar bugs, experimentar, etc. Sin afectar la versión estable.

Línea Master

Esta línea donde empezamos se le conoce como master, es la línea principal y estable del proyecto.

Creando una rama

Tenemos nuestra línea principal master (Trunks), pero digamos que alguien quiere crear una rama para hacer otras cosas llamada experimental (Goten).

Eso lo podemos lograr con:

git branch nombre de la rama

De ésta forma creamos una nueva línea (Rama) en la que nosotros podemos trabajar sin afectar a master

Extra

Para eliminar una rama se usa el comando:

git branch -d nombre de la rama

Concepto Head

Qué es?

Es la forma en que nos movemos de un punto a otro (commit), Nuestro HEAD es el punto en donde nos encontramos.

Fusiones

Qué es?

Es la creación de un nuevo commit que vincule una de nuestras ramas (trunks), con alguna otra rama (Goten), dando como resultado un nuevo commit (Gotenks).

Para hacer una fusión tenemos que seguir 2 pasos:

1. Situarnos en la línea que va a absorber.

Es la línea que absorbera la rama que nosotros deseamos, en este caso será experimental.

Lo logramos hacer con el comando antes visto checkout

git checkout nombre de la rama

2. Fusionar

Aquí es cuando nuestra línea que absorbe (Trunks) toma a la línea experimental (Goten) y nos dá nuestro nuevo commit (Gotenks).

Cuando se hace la fusión nos pueden dar 2 resultados diferentes:

• Fast-Forward -> Todo lindo y hermoso.
• Manual Merge -> Todo feo y horrible.

Fast-Forward

Simplemente hará la fusión sin preguntar nada, es cuando los gestores trabajan archivos diferentes al repositorio

Ejemplo:

• Filiberto Martínez -> index.html
• Miguel Nieva -> styles.css

Manual Merge

Es cuando dos desarrolladores o tú trabajan sobre el mismo archivo en la fusión

• Filiberto Martínez -> index.html
• Miguel Nieva -> index.html

git log & Aliases

En la terminal podemos igual ver como esta avanzando el proyecto, con el comando git log, de esta forma visualizaremos de forma simple y sintetizada el dibujo de las ramas.

El comando es:

Sabemos que es un comando largo y da pereza, para eso existen los aliases los cuales hacen que no tengamos que escribir todo, es poder poner nuestros comandos git como queramos con el nombre que sea.

git config --global alias.filigit '--oneline --graph --all'

Ahora simplemente para usarlo hacemos lo siguiente:

git log filigit

GitHub

Qué es?

Github es una comunidad o plataforma donde podemos almacenar nuestros proyectos, utiliza Git para su gestión.

Cada vez son más las personas que estan esta gran comunidad, la mayoria de ellas estan por el ámbito web, pero sin duda hay proyectos totalmente distintos.

Github además lleva un historial de tu código, guarda cada nuevo cambio que haces.

Git no es lo mismo que Github

Github se basa en tres áreas

• Colaboración: Gente que pone de su parte y abre sus ideas al mundo, no viven en el mundo de ¡Si lo pongo en Github, me lo roban!
• Creación: Si tienes proyectos, empresas, startups.
• Conexión: Conectas con el mundo profesional y tienes más probabilidades de ser contratado por tu portafolio.

Workflows

Qué es?

Son flujos de trabajo colaborativos.

Lograr trabajar con varios profesionales sobre el mismo proyecto sin morir en el intento.

Es la manera de como logras integrar todo tu equipo para que se alcance un proyecto completo.

Exploración: Git Clone

Cuando clonas proyectos, es cuando no te interesa colaborar, solo quieres ver el proyecto y tenerlo en la computadora

Se basan en dos comandos:

git clone [https]

git clone [SSH]

Solo tenemos que ir al proyecto que necesitamos, y justo a la derecha tenemos el https para clonar

Ya que estamos en la carpeta donde queremos tener el proyecto usamos el comando:

git clone [https]

Github Workflows están divididos en tres áreas:

1) Proyectos Propios

Somos los dueños, si alguien decide participar nostros decidimos si aceptamos las propuestas o no, y regularmente se usan para guardar proyectos personales.

Empezamos por crear un repositorio Local y Remoto.

Es decir crear un repositorio en nuestra computadora y otro en Github.

Ya que hicimos esto, Github no sabe que existe nuestra computadora, y nuestra computadora no sabe que existe Github.

Es cuando usamos:

git remote

git remote

Lo que hace es vincular nuestro repositorio local (Computadora) con nuestro repositorio remoto (Github).

Ejecutamos el comando:

git remote add origin Repositorio de github

De esta forma se vinculan y se conocen.

Para saber nuestros enlaces que hacemos via repositorio:

git remote -v

Finalmente ahora ya que trabajamos, hay que mandar esos cambios al repositorio de github

git push origin master

master -> Es la rama que mandaremos a github, obviamente podemos poner cualquier rama.

2) Proyectos propios (Yo + Equipo)

Es lo mismo que el proceso anterior, pero todos los cambios que hagan los colaboradores, podran hacerlos sin preguntar.

Ya no solo eres tú, si no que ya habrá alguien más.

Los colaboradores no piden permiso, suben cambios y se acabo.

Esto se explica a través de un proceso llamado:

git fetch & git merge

Cuando nosotros generamos un enlace remoto con un repositorio, hay una rama escondida llamada: origin/master y lo que haces es espejear el repositorio de github a tú área local.

git fetch

Lo que hace git fetch es espejear nuestro repositorio remoto con nuestro origin/master

Entonces para sincronizarnos usamos:

git fetch origin

Ahora lo que tenemos en remoto ya esta en la línea origin/master

Pero que pasa si yo creo commit totalmente distinto a lo que hay en origin/master ?

git merge

Ahora que tenemos dos commits totalmente distintos, llego la hora de fusionarlos y así crear un nuevo commit.

Para esto solo tenemos que estar en la rama principal y ejecutar:

git merge origin/master

git push

Finalmente ya que tenemos la fusión, ahora lo pasamos al repositorio remoto

Solo usamos el comando visto en el primer workflow.

git push origin master

3) Proyectos con terceros

Nosotros no somos dueños pero queremos participar en el desarrollo.

Todo dentro de un concepto de pull Request (PR).

Este tipo de repositorios trabajan bajo dos esquemas.

Necesitamos conectar dos repositorios porque cuando hacemos un fork es posible que ese proyecto se actualize y nosotros avancemos paralelo a otra cosa.

Una vez hecho el fork ahora conectamos los remotos.

Primero con el repositorio Fork

git remote add origin [http]

Seguimos con el siguiente remoto (El repositorio original)

git remote add upstream

Como vemos ya tenemos los dos remotos:

Ahora tenemos que espejear las dos ramas ocultas del proyecto:

git fetch origin

git fetch upstream

Esto va a hacer que tomemos los ultimos cambios en:

• Repositorio Fork
• Repositorio Original

Ya que tenemos los últimos cambios, ahora hay que darselos a nuestra rama master y así se actualize junto con los nuestros.

git merge origin/master

git merge upstream/master

Ahora ya que tenemos todo en nuestro repositorio local, tenemos que pasarlo a nuestro repositorio remoto (repositorio fork) que esta en github.

git push origin master

importante

Desayuna git fetch

Come git fetch

Cena git fetch

Deployment

Qué es?

Son todas las actividades que hacen a un proyecto de software disponible para su uso, es la manera en que haces publico tus proyectos, la forma en que te mueves y los llevas al mundo.

Environments (Ambientes)

Hay cuatro ambientes regularmente en los equipos profesionales web.

• Development
• Production
• Testing
• Staging

Development

Es nuestra área local (PC, Laptop), es donde creamos código y nos pasamos horas divirtiendonos, siendo mejores profesionales.

Production

Es un repositorio remoto (Online, Web), puede ser en Github o algún otro servidor, es nuestro sitio final, el que le mostramos al mundo.

Testing

Funciona para que nosotros generemos un test, exámenes para encontrar fallos en los códigos.

Staging

Es un servidor extra básicamente, en ves de subir el proyecto a production primero pasas por staging y verificamos si todo va bien.

Github Pages

Qué es?

Con Github Pages podemos generar un proyecto de nuestro repositorio permitiendonos mostrarlo a travez de un dominio, el unico problema es que no podemos usar backend, pero es muy util para portafolios, blogs y todo tipo de paginas del lado del frontend totalmente gratis

Para ello solo tenemos que crear una nueva rama de nombre gh-pages y acoplarlo con nuestro nombre de usuario un ejemplo es esta presentación simplemente ve el url, si quieres saber más de este tema:

Github Pages

Portafolios con GitHub Pages

Todos los cambios y modificaciones que hagamos en la rama gh-pages se aplicaran a la pagina como tal.

Conectar por SSH

SSH es una forma segura de conectar con Github.

A diferencia de HTTP no pide el usuario y contraseña porque con SSH sabe quien eres tu.

Primero hay que generar la llave:

$ ssh-keygen

Creara una carpeta .ssh oculta, que por lo general se encuentra en el Home.

Nota: si este comando no te funciona en windows, descarga: msysgit

Nos movemos a esa carpeta, y dentro nos encontramos con dos archivos que nos interesan:

• id_rsa.pub -> Llave publica, es la que le entregamos al servidor o a alguna persona.
• id_rsa -> Llave privada, jamas hay que perderla ni compartirla.

Para analizarla usamos:

$ cat id_rsa.pub

Esto nos mostrara un código muy raro, lo copiamos absolutamente todo.

Ahora vamos a Github / Settings / SSH keys / Add SSH Key

Nos pedira un título y una llave, el título puede ser el que sea, pero en la llave pondremos lo que copiamos en la terminal.

Por ultimo damos click en Add key

Nos dirijimos al repositorio remoto en github y copiamos el SSH, en la terminal nos dirijimos a nuestro proyecto local, y ejecutamos:

git init

Ahora hay que conectar via SSH con el repositorio remoto

git remote add origin [SSH]

Hacemos un git pull (fetch + merch) a la rama master

git pull origin master

Pero como estamos trabajando con github pages usamos:

git pull origin gh-pages

Por ahora no aparece la rama gh-pages ya que esta oculta, para empezar a usarla:

git checkout gh-pages

Ahora si ya podemos trabajar y hacer el deployment

1) Trabajar en código

2) git status

3) git add -A

4) git commit -m "Mensaje"

5) git push origin gh-pages

Manual Deployment

Bueno primero tenemos que dejar en claro que remote repository (Github) es un servidor, cuando nos conectamos a un servidor este mismo puede conectarse con otro servidor.

Esto se le conoce como infraestructura de servidores.

La forma correcta de autenticación es con SSH, esto dice ¿eres tu el propetario de estos tres ambientes?.

Si nosotros tenemos la llave nosotros podemos entrar a todos los candados, es decir los diferentes repositorios o servidores.

Eso basicamente es deployment

Ahora lo que tenemos que hacer es que a ese dominio o aplicación que acabamos de crear generar un repositorio con nuestra amiga la terminal.

Entramos remotamente desde la terminal al servidor.

$ ssh kakaroto@web396.webfaction.com

Recuerda que la dirección SSH varia segun tu servidor.

Nos dara la dirección para entrar de forma remota, esto igual depende del servidor, pero siempre nos la tiene que dar.

Ponemos nuestra contraseña, puede ser la misma o distinta a key que usamos con github.

Una vez hecho esto, ya estamos conectados de forma remota a travez de SSH

Qué sigue ?

Ahora tenemos que conectar la llave SSH que tenemos al servidor pero desde github y que no tenga ningun problema para mandarse información.

Esto lo logramos con:

$ ssh-keygen

Nuevamente nos genera una llave publica y privada

Entramos a la llave publica y nuevamente copiamos el código encriptado.

Para obtener el código recuerda usar:

$ cat id_rsa.pub

Vamos a Github / Settings / SSH keys / Add SSH Key

Nos pedira un título y una llave, el título puede ser el que sea, pero en la llave pondremos lo que copiamos en la terminal (Servidor).

Por ultimo damos click en Add key

¡Bien!, ya generamos una llave publica ahora con el servidor.

Recordar que estamos conectados a un servidor externo y no a nuestro PC.

Empecemos a conectar Github con nuestro servidor, regularmente tenemos comandos de git, en caso de que no tengamos git en el servidor, tenemos dos opciones:

Ahora si podemos empezar a traer el proyecto desde github.

Issues

Mini-bonus por mi

Esta es una pequeña ayuda que proporciono, pero básicamente hablare de lo mismo y de forma que tu lo puedas entender.

Qué es?

Los issues es una forma de dar seguimiento, mejorar o resolver un error de nuestros proyectos.

Creando un Issue

Para crear un issue tenemos que ir a nuestro repositorio en Github / settings y en la parte de Features activamos Issues.

Una vez hecho esto en la parte derecha nos saldra un nuevo icono, damos click.

Ahora damos click en New Issue, aquí es donde elegimos un título y una pequeña descripción de lo que se debe de hacer.

En el issue hay una parte que dice No one is assigned que básicamente es: No has asignado el issue a nadie así que damos click en el engrane y seleccionamos a alguien incluso podemos a nosotros mismos.

De esta forma la persona que seleccionamos es la que tiene que hacerse cargo de ese issue.

Ya que tenemos todo esto damos click en:

Submit new issue

Ahora esta nuestro issue creado, y podemos hacer aun más...

Si entramos al issue podemos tener conversaciones con el equipo acerca de lo que pasa, poner imagenes o finalmente cerrar el issue porque se resolvio.

Que pasa si tenemos una gran cantidad de issues, es posible que sea dificil encontrarlos, para eso tenemos:

Milestones

Labels

Milestones

Son grupos de issues que corresponden a un proyecto, característica, o periodo de tiempo.

Ejemplo:

Issues de Betas

Issues para Enero

Issues para Rediseño

Para crearlos solo tenemos que ir a Milestone

Damos click en el boton de New milestone

Como podemos tenemos que asignar un título, una descripción y una fecha de vencimiento (opcional), hecho esto, damos en create milestone.

Ahora cuando creamos un issue podemos meterlo dentro de un milestone, de esta forma podemos llevar el control.

Labels (etiquetas)

Son una gran manera de organizar diferentes tipos de problemas. Los problemas pueden tener todas los labels que sean y se pueden filtrar por una o varias labels a la vez.

Git nos proporciona algunos labels por defecto pero igual nosotros podemos crear los nuestros.

Damos click en New label, asignamos un nombre y un color, finalmente damos click en Create label.

Así de sensillo es crear labels

Podemos asignarlos a nuestros issues y tener una buena organización.

Si no te quedo claro los issues

Da click aquí

Shell Scripts

Qué es?

Son una serie de comandos encapsulados dentro de un archivo.sh, se ejecutan con la terminal, y van de arriba a abajo.

Si por alguna razón tienes problemas en windows, descarga cygwin

Solo tenemos que crear nuestro archivo .sh y empezar a escribir nuestras instrucciones

Para ejecutar este shell script y se aplique todo lo que tiene:

sh nombre.sh

git hooks

Qué es?

Son scripts que se ejecutan antes, durante o después de realizar un movimiento con git.

Estos scripts son archivos .sh, y constan de 17

post-commit

Este hook se ejecuta después de generar un commit

Es decir una ves que nosotros usemos

git commit -m "mensaje"

Este hook va a ejecutarse automáticamente.

Para ello primero tenemos que ir a la carpeta hooks:

cd .git/hook

Nota: debemos haber iniciado git antes en la carpeta de nuestro proyecto

git init

No está nuestro hook, así que tenemos que crear

touch post-commit

Para editar usamos:

vim post-commit

Dentro ponemos

#!/bin/sh

git push origin master

Ahora ya que tenemos guardado esos comandos en post-commit hay que dar permisos:

chmod +x post-commit

Listo ahora ya tenemos el hook activado solo tenemos que generar el commit:

git remote add origin [SSH]

git add -A

git commit -m "Usando hooks"

Lo que paso es que se hace un push pero sin tener que ejecutarlo, los hooks son tus amigos y lo hacen por tí.

Automatic Deployment

Básicamente un Automatic Deployment es un manual deployment pero automatizado.

Primero hay que crear nuestra llave SSH dentro de nuestro servidor.

ssh-keygen

La obtenemos con:

cat id_rsa.pub

La copiamos y vamos a Github / settings/ add SSH key / agregamos llave

De esta forma logramos conectar el servidor con Github.

Antes de empezar con lo siguiente tenemos que lograr conectar el Local Repository con Github vía SSH

Nosotros ya sabemos hacer eso así ¡que que esperan! :D

1) Creamos carpeta

mkdir portafolio

git init

git remote add origin [SSH]

git remote -v

2) Jalamos archivos (si es necesario)

git pull origin master

3) Creamos archivo .gitignore & deploy.sh

Nota: El archivo .gitignore lo que va hacer es no tomar los archivos .sh del repositorio.

touch .gitignore

vim .gitignore

Dentro de .gitignore ponemos: *.sh

touch deploy.sh

4) Generamos Cambios

Lo que haremos es editar nuestro index.html

5) Creamos el Git HOOK y lo llenamos

cd .git/hooks

touch post-commit

vim post-commit

Dentro de post-commit:

#!/bin/sh

git push origin master

ssh miguelnieva@web396.webfaction.com 'bash -s' < deploy.sh

6) Autorizamos el Git Hook

chmod +x post-commit

7) Llenamos los comandos que se ejecutatan en servidor (deploy.sh)

cd ../..

vim deploy.sh

Dentro de deply ponemos lo siguiente:

#!/bin/sh

cd ~/webapps/portafolio -> Según tu servidor

git init

git remote add origin [SSH]

git pull origin master

Ahora probamos

git status

git add -A

git commit -m "Deploy 1"

Lo que va a pasar es lo siguiente:

¡Listo! ya hicimos deployment automático

Deploy total en server

Si por alguna circustancia extrema, no podemos usar Github, existen los "bare respositories", que no son más que repositorios limpios, envian y reciben contenido.

Un bare repository unicamente guarda el historial de cambios, con todos sus archivos, pero no puedes editarlos.

Un bare repository ¡¡¡jamás se toca!!!

Primero creamos nuestras dos carpetas o aplicaciones en servidor.

• gitcentral -> Guarda todos nuestros repositorios "bare" y solo va a recibir/enviar información.
• deployserver -> Mostrara nuestro resultado, ya pasando por el "bare".

Entramos a nuestro servidor via SHH (Ya sabemos como) y borramos los index.html que tienen.

Ahora lo se hara es lo siguiente: normal repository (local) suba cambios al bare repository y que normal repository (server) reciba esos cambios.

Empecemos

Local

Creamos nuestra carpeta y un archivo index.html

mkdir proyecto

touch index.html

Editamos nuestro index

vim index.html

Creamos el commit

git init

git status

git add -A

git commit -m "Commit 1"

Servidor (Bare repository)

Entramos al servidor vía SSH y nos movemos hasta la carpeta

ssh goku@web396.webfaction.com

cd/webapps/gitcentral

Ejecutamos git init

git init --bare --share

--bare -> Porque este repositorio va a ser un "bare".

--share -> Para que lo puedan pushear diferentes usuarios.

Local

Ahora tenemos que subirlo al servidor directamente, y mandamos cambios:

git remote add origin goku@web396.webfaction.com:home/goku/webapps/gitcentral

git push origin master

Servidor (normal repository)

git init

git remote add origin ../gitcentral

git pulls origin master