Git, GitHub y Publicación Web
Índice
- 1. Instalación de git
- 2. GitHub
- 3. Llave SSH
- 4. Cambiar el editor por defecto
- 5. Configuración
- 6. Crear un repositorio
- 7. Clonar un repositorio
- 8. Estado del repositorio
- 9. Información de cambios en el repositorio
- 10. Añadir y modificar documentos
- 11. Renombrar archivos o directorios
- 12. Actualizar repositorio
- 13. Deshacer cambios
- 14. Pull request
- 15. Borrar rama
- 16. Mantener un repositorio forkeado actualizado
- 17. Publicación web
- 18. Gitignore
- 19. Problemas
- 20. Pruebas
- 21. Bibliografía
Notas sobre git y Github:
- git
- github
- gestión de proyectos
- crear copias de proyectos
- adaptar proyectos
- participar en proyectos.
Puedes trabajar con git desde herramientas gráficas o desde la línea de comandos.
En este caso vamos a trabajar con la línea de comandos, preferiblemente en GNU/Linux.
1. Instalación de git
En GNU/Linux, tan solo hay que instalar git-core
:
apt-get install git-core
En Mac se puede instalar el instalador gráfico de git y en Windows, git for Windows.
Para usar git desde la terminal en Mac hay que activar las funciones de Xcode.
Si queremos disfrutar de una terminal potente, podríamos usar Cygwin en Windows o la Terminal en Mac.
Comprobamos que se ha instalado git con la opción --version
git --version
También tenemos los instaladores oficiales de git:
2. GitHub
Crea una cuenta en GitHub
Si no te atreviste con el paso anterior, puedes usar estos programas de escritorio para Windows y Mac:
- Windows: http://windows.github.com y primeros pasos
- Mac OS X: http://mac.github.com y primeros pasos
- Wiki
En GitHub se puede añadir el wiki como un submódulo, tal como recuerdan aquí:
git submodule add git://github.com/you/proj.wiki
Que podríamos enlazar con nuestro directorio preferido:
git submodule add git://github.com/you/proj.wiki vocabulary
Ahí debería haber al menos dos archivos:
Home.md
, donde estaría la información de portada del wiki._Sidebar-vocabulary.md
, el menú de la derecha del wiki._Footer.md
, información al pie.
- Qué son los submódulos
Como su propio nombre indica, son parte de un repositorio git. A efectos prácticos, funcionan como un subrepositorio, un repositorio dentro de un repositorio.
Para qué se pueden utilizar:
- Se pueden utilizar para separar código en submódulos.
- Pueden ser parte de más de un repositorio, por lo que pueden compartirse con otros proyectos/repositorios, de tal forma que cuando se actualice ese submódulo se actualizará en todos los repositorios donde está como submódulo.
- Funcionamiento
Cuando añades un submódulo a un repo, añades el código al repo y queda registrada la información que describe a qué commit está apuntando el submódulo. El archivo
.gitmodules
almacena la versión del submódulo cuando es añadido. - Añadir un submódulo
Se añade un submódulo de la siguiente manera:
git submodule add git@github.com:url_a/mi-submodulo.git ruta-donde-quiero-el-submodulo
De esta manera se pasa el código y se añade información al repositorio principal sobre el submódulo, lo que contiene el commit a donde apunta el submódulo, que será el commit de la rama por defecto.
- Obtener el código
Si se crea el submódulo, las otras personas tienen que inicializar el submódulo. Primero obtienes la información con
git fech
o bien descargamos información y código congit pull
y después se inicializan congit submodule init
.Si se clona un repositorio con submódulos, también se tiene que correr este comando para obtener el código del submódulo ya que no lo hace automáticamente con
git clone
. - Actualizaciones del submódulo
Si actualizamos el submódulo, dado que es un repositorio separado, también tendremos que actualizar el repo principal ya que su último commit apunta al anterior. Para actualizar, desde el repo principal,
git add
,git commit
ygit push
. - Mantener actualizados los submódulos
Si otras personas hicieron cambio en el submódulo, hay que actualizar el código con
git submodule update --remote
. - Truco
Si lanzamos
git submodule update --init
, inicializamos los submódulos.En caso de tener submódulos dentro de submódulos, añadimos
--recursive
al final de la sentencia.Recuerda que se pueden hacer
alias
engit
, por lo que podríamos crear uno tal que así:git config --global alias.update '!git pull && git submodule update --init --recursive'
De tal forma que con
git update
inicializaríamos correctamente el repositorio y el/los submódulo(s). - Gestión de submódulos
mdlr
se declara como una herramienta de git para gestionar submódulos fácilmente.
3. Llave SSH
Si no sabes qué es SSH, sáltate esto
Las claves SSH son una forma de identificar ordenadores de confianza sin comprometer contraseñas. Se peude generar unas claves SSH y añadir la clave pública de GitHub para que se produzca la conexión.
GitHub recomienda revisar regularmente la lista de claves SSH y revocar aquellas que no se usen, no se hayan usado o no se vayan a usar.
Puedes conectarte por ssh y activar la llave ssh para conectarte de forma autentificada automáticamente. Vayamos paso a paso.
- Comprobación de claves
Primero comprobamos que contamos con clave ssh en el equipo:
ls -la ~/.ssh
Si aparece un listado de claves, podremos saltarnos el siguiente paso. Si no, debemos generar unas claves.
- Generar claves ssh
Necesitas generar una clave ssh el equipo local desde el que te conectas:
ssh-keygen -t rsa -b 4096 -C "correo-electronico@dominio.com"
Lo cual crea una nueva clave ssh y utiliza el correo electrónico como etiqueta.
Si todo va bien, mostrará el mensaje de generación de la clave, pedirá dónde almacenarla y se puede añadir una contraseña:
Generating public/private rsa key pair. Enter file in which to save the key (/home/usuarix/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/usuarix/.ssh/id_rsa. Your public key has been saved in /home/usuarix/.ssh/id_rsa.pub. The key fingerprint is: (...)
(...)
es donde aparece la clave.Ahora que ya tenemos la clave, la pegamos en GitHub en las preferencias, en el apartado "SSH and GPG keys".
- Copia de clave con método
pbcopy
Para seleccionar la clave, podemos emplear el método MacOSX
pbcopy
, que podemos hackear en GNU/Linux con un alias a partir dexsel
:alias pbcopy='xsel --clipboard --input' alias pbpaste='xsel --clipboard --output'
De esta forma ya podemos utilizar
pbcopy
:pbcopy < ~/.ssh/id_rsa.pub
Y pegamos en GitHub. A partir de ahí ya podremos conectarnos con GitHub de forma segura.
- Copia de clave con
more
y copiar y pegar
Podemos hacerlo en dos pasos, mostrando la clave y copiándola con el ratón:
more ~/.ssh/id_rsa.pub
- Copia de clave con método
- Configuración local y comprobación
Ya está casi todo hecho. Ahora falta decirle a git que nos conectamos a GitHub de forma segura. Para ello, podemos comprobar que lo podemos hacer, y en el mismo paso aprobar la conexión:
ssh -T git@github.com
Nos pedirá la contraseña que hayamos puesto a la clave si lo hemos hecho, lo introducimos y listo. Si no, nos saldrá directamente el mensaje:
The authenticity of host 'github.com (192.30.252.1)' can't be established. RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48. Are you sure you want to continue connecting (yes/no)?
Nótese que
192.30.252.1
es una de las direcciones IP de GitHub, pero podría salir otra. Lo más importante es fijarse en el fingerprint.Le decimos que sí y entonces GitHub nos responde:
Hi usuarix! You've successfully authenticated, but GitHub does not provide shell access.
Donde
usuarix
es nuestrx usuarix en GitHub. Ya está hecho.Si nos apareciese el mensaje
access denied
, recomiendo seguir los pasos anteriores o este artículo de GitHub para comprobar que lo hemos hecho bien.
4. Cambiar el editor por defecto
Por defecto, bash y git vienen con el editor vi
por defecto. Para cambiarlo, tal como explican en stackoverflow, podemos hacerlo en una o en
ambas.
- core.editor
Para usar
nano
o el editor de texto CLI de nuestra elección, corremos:git config --global core.editor "nano"
La opción
--global
es para hacerlo en todo git. Si solo quisiéramos en este repositorio, sería sin esa opción. - nano como editor por defecto
Lo hacemos en dos líneas, con dos variables de entorno:
export VISUAL=nano export EDITOR=$VISUAL
5. Configuración
La primera vez que usas Git te pedirá tu nombre de usuarix y dirección de correo. Lo podemos agregar con el comando config
.
Tal como comenta sarigalin hay tres niveles de configuración de git
, de más específico a más general, siendo
la más específica la que sobreescribe la más general.
project
, configuración de proyecto, solo disponible para el actual proyecto. Se almacena en.git/config
en el directorio del proyecto.global
, configuración global para todos los proyectos del usuario del sistema. Se almacena en~/.gitconfig
.system
, configuración para el sistema, para todas las cuentas del sistema.
Por tanto, si queremos tener una configuración para el sistema, escribiremos:
git config --system user.name "Fulanito de Tal"
Si queremos que sea global para nuestra cuenta:
git config --global user.name "Fulanito de Tal"
Y si queremos que sea especifica del repositorio, que es la configuración por defecto, no hay que añadir
--project
como en los otros dos casos.
git config user.name "Fulanito de Tal"
- Configuración global
Añado el nombre de la cuenta, en este caso el nombre de usuarix en GitHub:
git config --global user.name "Nombre_de_Usuarix"
Añado la dirección de correo electrónico:
git config --global user.email "usuarix@dominio"
Si no queremos aplicar esta configuración a todo el sistema y solo a este repositorio porque manejamos más usuarixs de GitHub, por ejemplo, no pongáis la opción
--global
Cuando hagamos luego
git push
, nos pedirá el usuario y contraseña por https:Username for 'https://github.com': usuarix Password for 'https://usuarix@github.com':
6. Crear un repositorio
- Opción GitHub al final
Podemos iniciar el proyecto git en un directorio cualquiera, ya creado, o bien crearlo en uno nuevo.
- Nuevo repositorio en directorio nuevo
Si queremos crearlo en uno nuevo, iniciamos el repositorio con la opción
init
seguida del nombre del directorio:git init nombre_repo
- Nuevo repositorio en directorio existente
También podemos crear un directorio con
mkdir
y luego inicializar ese directorio solo con la opcióninit
:mkdir nombre_directorio cd nombre_directorio git init
- Pasarlo a GitHub
Para que el repositorio o proyecto también esté en GitHub, vamos a Github y creamos un proyecto nuevo que llamamos con el nombre del directorio que hemos creado o del directorio que ya existía.
No marques la opción Initialize with README y tampoco le asignes licencia, vamos a crear un repositorio vacío para que nos sea más fácil realizar el primer
push
.Conectamos el directorio local donde nos encontramos con GitHub de la siguiente manera:
git remote add origin https://github.com/cuenta/nombre-repositorio
Donde le decimos a
git
que añadimos ungit
remoto en la URL de GitHub.Hemos de crear al menos un archivo README.md donde puedes poner la información del proyecto:
echo "# Otro proyecto ni más ni menos" >> README.md
Añadimos el archivo a git:
git add README.md
Lo comiteamos:
git commit -m "mi primer commit"
Y lo subimos a GitHub:
git push -u origin master
- Nuevo repositorio en directorio nuevo
- Opción GitHub
Primero creas un repositorio con un nombre en Github.
Github te sugiere varias formas de copiarlo en local, en el propio ordenador. Os recomiendo seguir estos pasos:
echo "# Proyecto de ..." >> README.md git init git add README.md git commit -m "primer commit" git remote add origin https://github.com/cuenta/nombre-repositorio git push -u origin master
- Comprobaciones
Comprobamos su estado con la opción
status
:git status
Si listamos el directorio, comproboremos que tenemos un directorio oculto llamado
.git
ls -la
Cuando quieras que el directorio deje de ser un repositorio git, tan solo hay que borrar este directorio oculto con
rm -rf
:rm -rf .git
Si en este caso podríamos saber el status de git, el mensaje nos avisaría diciendo que no se trata de un repositorio git.
7. Clonar un repositorio
Vamos a cualquier proyecto de GitHub y copiamos la URL que aparece en la casilla de HTTPS. En este caso, vamos a clonar el proyecto Boilerplate de Paul Irish:
git clone git://github.com/paulirish/html5-boilerplate.git
Si en vez de clonar un repositorio lleno queremos hacerlo vacío, hay que poner:
git clone --bare https://github.com/exampleuser/old-repository.git
8. Estado del repositorio
Podemos ver el estado del repositorio con la opción log
git log
Que nos da toda esta información:
- La lista de cada
commit
- El hash SHA1 del commit, una cadena única de cada commit
- La autoría
- El mensaje que describía el cambio
9. Información de cambios en el repositorio
Si queremos ver los cambios en esta versión, debemos utilizar la opción diff
:
git diff
10. Añadir y modificar documentos
11. Renombrar archivos o directorios
- Renombrar un archivo
git mv archivo1 archivo2 git add archivo2 git push -u origin master
- Renombrar un directorio
git mv directorio1 directorio2 git add directorio2 git push -u origin master
Ver los cambios que vamos a realizar con la opción
-n
, el atajo de--dry-run
git mv -n nombre_directorio_antiguo nombre_directorio_nuevo
- Case sensitive
Renombrar en sistemas que no distinguen entre mayúsculas y minúsculas, puede dar un error cuando modifiquemos el nombre por caracteres en mayúsculas, por lo que tendríamos que hacer:
git mv directorio1 tempname && git mv tempname Directorio2
Si nuestro sistema no es case sensitive, puede ocurrir que queramos tener dos ficheros que se llaman igual, pero uno emplea mayúsculas y otro minúsculas, y git no nos lo deje incluir.
Por ejemplo, si tenemos
TFM.html
ytfm.html
en local, y añadimos a git uno de ellos, luego no podremos añadir el otro a no ser que configuremos nuestro git como case sensitive:git config core.ignorecase false
Ahora ya podremos hacer
git add
con éxito.La solución viene de Stackoverflow
- Borrar del repositorio
Borrar un archivo del repositorio sin borrarlo del sistema de directorios local:
git rm --cached archivo.org
- Borrar un directorio
Para borrar un directorio:
git rm --cached -r directorio
12. Actualizar repositorio
Si queremos actualizar el repositorio con los cambios que se hayan producido en él, lo haremos con la opción pull
:
git pull
13. Deshacer cambios
Si realizamos un commit
pero queremos volver atrás, si no hemos realizado push, es:
git reset --hard HEAD-1
Si hemos realizado el commit
lo mejor es hacer revert, tal como explican
git revert <hash-or-ref>
Para saber el hash-or-ref
se puede consultar la parte de Commits de la página del repo o
bien con el comando git log --pretty=online
.
Luego hacemos git push
para actualizar el repositorio con el cambio revertido.
14. Pull request
Haremos un pull request cuando queramos contribuir con nuestros cambios -mejoras, corrección de errores, actualizaciones- a un repositorio que ya existe.
Por eso, lo primero que tenemos que hacer es crear una copia del proyecto:
git clone ruta-proyecto.git
Luego creamos una rama donde hacer las modificaciones:
git checkout -b nueva-rama
Al crearla nos movemos a esa rama. Podemos comprobarlo si tenemos el asterisco en la rama deseada:
git branch
Si no estamos ahí, vamos con:
git checkout nueva-rama
Luego hacemos las modificaciones que sean a nuestros archivos, las añadimos, las comiteamos y las subimos a la rama creada:
git add ruta-nuevos-archivos
git commit -m "comentario sobre cambios"
git push -u origin nueva-rama
Comprobamos el estado de git con git status
git status
Si todo está bien, vamos a nuestra copia del proyecto en Github y en la página del repo pondrá que hay una rama sobre la que hacer un pull-request, pinchamos y seguimos los pasos.
Si no hay discusión, si está todo bien, el administrador lo aprobará y entonces podremos borrar la rama. Nos movemos a master y desde ahí borramos en local y en el servidor:
git checkout master git branch -d nueva-rama git push origin --delete nueva-rama
15. Borrar rama
En local:
git branch -d rama-local
Si no se borra así, con -D
git branch -d rama-local
En remoto::
git push origin --delete rama-remota
o también:
git push origin :ramaremota
16. Mantener un repositorio forkeado actualizado
Añades remoteando
como servidor remoto:
git remote add remoteando git://ruta-repositorio.git git remote add remoteando https://github.com/cuenta/nombre-repositorio.git
Actualizas remoteando pero sin integrar los cambios
git fetch upstream
Integras los cambios con la versión local:
git pull upstream master
17. Publicación web
Si el contenido del proyecto es HTML, podemos utilizar a GitHub como servidor web de nuestro contenido web, a través de la funcionalidad Pages.
Se puede hacer de dos maneras:
- Nombre del repositorio
Si el nombre del repositorio sigue la estructura "nombre-de-usuarix.github.io", el proyecto que cuelgue de ahí se publicará automágicamente en http://nombre-de-usuarix.github.io
- Rama gh-pages
Cualquier repositorio que tenga la rama
gh-pages
será publicado, y se verá su contenido web.Por ejemplo, si tenemos un repositorio con nombre
mi-proyecto
que contiene una web y queremos publicarlo como página web, solo tenemos que crear una nueva ramabranch
de nuestro proyecto que llamaremosgh-pages
:git checkout -b gh-pages
Luego ponemos ahí todo el contenido de la rama
master
:git merge master
Por último subimos a GitHub todo lo que tenemos en la nueva rama:
$ git push -u origin gh-pages
En unos minutos, GitHub lo habrá publicado en una URL del tipo http://nombre-de-usuarix.github.io/mi-proyecto
Si tu repositorio es solo una web, puedes optar por utilizar solo la rama
gh-pages
en vez de mantener las dos ramas. Para ello tienes que elegir en GitHub qué rama utilizas.Si mantienes las dos, actualizar la web se puede convertir en algo tedioso si lo haces habitualmente.
Para facilitar la tarea, brettterpstra.com recomienda una solución, puedes editar
.git/config
y añadir estas líneas a[remote "origin"]
:push = +refs/heads/master:refs/heads/gh-pages push = +refs/heads/master:refs/heads/master
Quedando así:
[remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = git@github.com:user/repo.git push = +refs/heads/master:refs/heads/gh-pages push = +refs/heads/master:refs/heads/master
De esta manera, cuando hagas git push lo harás en los dos repos.
18. Gitignore
19. Problemas
- 403 fatal: HTTP request failed
git remote set-url origin https://yourusername@github.com/user/repo.git
- git: error: src refspec master does not match any
http://stackoverflow.com/questions/10568641/git-error-src-refspec-master-does-not-match-any
git remote rm origin git remote set-url origin git@.... git push -u origin master
- Please, commit your changes or stash them before you can merge.
Si alguien o tú mismo en otro equipo ha actualizado el repositorio mientras tú trabajabas y te sale este error, sin entrar en las opciones con las ramas, tienes tres opciones: