Quitter España
  • FAQ
  • Login
Hoy es el Día Internacional de la Mujer también!
Apoyad el sitio con BTC o PayPal | Administrador: @perro
  • Public

    • Public
    • Network
    • Groups
    • Popular
    • People

Maisun (martinho@quitter.es)'s status on Wednesday, 22-Mar-2017 20:10:52 CET

  1. victorhck (victorhck@quitter.no)'s status on Wednesday, 22-Mar-2017 19:14:40 CET victorhck victorhck
    Remote profile options...
    Las pocas cosillas de #git que he aprendido las he apuntado por el blog por si sirven y para que no se me olviden:

    - Crear alias de comandos de git: https://quitter.no/url/1022361

    - un tutorial muy básico de cómo lo empecé a utilizar: https://quitter.no/url/1022362

    - mantener actualizado un fork: https://quitter.no/url/766689

    - modificar el texto de un commit: https://quitter.no/url/1022363

    - recuperar un archivo o un repo a una versión anterior: https://quitter.no/url/732562
    In conversation about a year ago from quitter.no permalink Repeated by martinho

    Attachments

    1. File without filename could not get a thumbnail source.
      Git: recuperar un archivo o todo el repositorio a una versión anterior
      By victorhck from victorhckinthefreeworld

      Tutorial de Git sobre cómo recuperar un archivo en concreto o todo el repositorio a una versión anterior en la que todo funcionaba bien.

      ¿Utilizas Git como control de versiones para tus proyectos? ¿Te estas iniciando en el uso de Git y quieres aprender más? Una de las buenas opciones que nos proporciona git es la posibilidad de probar cosas y ante un problema poder recuperar un archivo o todos a una situación en la que sabíamos que todo funcionaba bien.

      Partimos de la base de que conoces qué es Git, que conoces lo básico y que en algún momento lo has utilizado para alguna tarea.Todos cometemos errores, pero herramientas como Git nos viene a solucionar algunos de esos errores y problemas en lo referente al código.

      Imagina que modificas un archivo y parece que todo está bien, lo añades (git add) y realizas un “commit” de la modificación (git commit).

      Después de eso decides que ese archivo necesita un “último ajuste” y finalmente el archivo queda completamente irreconocible y quizás no funcionando como esperabas. ¿Qué podemos hacer?

      Podemos recuperar el archivo (prueba.txt en los ejemplos siguientes) al estado en el que estaba antes de la modificación, es decir al estado en el que estaba en el último “commit” para eso utiliza el comando git checkout al último commit conocido que en este caso está en HEAD:

       git checkout HEAD prueba.txt

      Pero si esa versión no es buena, o si quieres volver el archivo en cuestión no a esa versión si no a una anterior en el tiempo, primero deberemos comprobar en el registro log de ese directorio de git los “commits” realizados para poder escoger a la versión que deseamos. Echamos un vistazo a los logs con este comando:

       git log --oneline

      Lo que nos dará una salida “algo” similar a esta (con las lógicas diferencias de “commits”, etc…)

      79a4e5f commit prueba
      f449007 segundo commit
      55df4c2 Primer commit del proyecto.

      Imaginemos que queremos devolver el archivo prueba.txt a la versión como estaba en nuestro primer commit del proyecto. Para ello escribiremos el siguiente comando

       git checkout 55df4c2 prueba.txt

      Ahora la versión antigua del archivo ha sido restaurada en el directorio de trabajo. Puedes comprobar el estado del directorio de trabajo mediante el comando git status. No olvides que una vez restaurado el archivo, es necesario volver a añadir el archivo y volver a hacer un “commit” ya que el archivó cambió.

       git add prueba.txt
       git commit -m 'restaurar prueba.txt al estado del primer commit.'
      

      Comprobemos en el log de Git que efectivamente todo ha ido como queríamos:

      git log --oneline
      d512580 restaurar prueba.txt al estado del primer commit.
      79a4e5f commit prueba
      f449007 segundo commit
      55df4c2 Primer commit del proyecto.

      También podemos llevar no sólo un archivo a un punto predeterminado, si no todos los archivos del repositorio, para ello escribimos:

      git checkout 55df4c2

      Al hacer esto, tu repositorio va atrás en el tiempo por completo, así que si ahora empiezas a trabajar sobre él podrías destruir tu futuro trabajo. Por defecto Git asume que no es eso lo que quieres hacer, así que separa donde se desarrolla el trabajo HEAD del proyecto y te deja empezar a trabajar.

      Aquí habría que empezar a hablar de las ramas o “branch” y de cómo trabajar con ramas paralelas del proyecto, pasar de HEAD a las ramas y finalmente unir la que deseemos. Pero eso ya para otro artículo.

      Espero que os haya quedado claro cómo volver a una versión antigua de un archivo, que era el tema de este artículo. Os animo a probar con unos directorios y archivos de prueba y ver cómo evoluciona el archivo trabajando con Git y devolverlo a diferentes estados.

      Este artículo ha estado inspirado en este escrito en inglés por Seth Kenlon para opensource.com, que podéis encontrar en este enlace:

      • https://opensource.com/life/16/7/how-restore-older-file-versions-git

      Os aconsejo toda la serie de artículos que está preparando, y quizás de alguno más encontraréis en mi blog su adaptación ¿os parecen interesantes?

      Enlaces de interés a otros artículos sobre Git:

      • Curso interactivo de Git en 15 minutos
      • Chuleta de comandos de Git
      • Un libro para conocer y manejar Git
      • Git y GitHub tutorial básico en GNU/Linux

      Pichar sobre la imagen para ampliar y poder descargar

      ——————————————————-

    2. File without filename could not get a thumbnail source.
      Git: mantener un fork de un repositorio actualizado
      By victorhck from victorhckinthefreeworld

      Tutorial de git en el que veremos cómo mantener un fork de un repositorio actualizado con los cambios que se hagan en el original.

      Esta es la situación:

      1. Queremos colaborar con código en un repositorio que se encuentra en un servicio de hospedaje (como por ejemplo GitLab o GitHub).
      2. Como en el repositorio oficial no tenemos permisos para hacer modificaciones, hacemos un “fork” del repositorio original en nuestro espacio, clonamos este “fork” trabajamos sobre él.
      3. Después de subir nuestros commits hacemos un “pull request” para que el desarrollador del repositorio original lo revise y acepte o no dicho “pull request”.
      4. Pero ¿cómo mantenemos nuestro “fork” actualizado con las modificaciones que el desarrollador vaya incorporando en el proyecto original? Esa pregunta es la que quiere responder este artículo.
      5. Imaginemos que tanto el repositorio original como el “fork” están en GitHub.

      ¿He explicado bien cual es el meollo de la cuestión?

      La cosa es saber cómo mantener nuestro fork actualizado, para si en un futuro queremos volver a participar en otra cuestión, este este actualizado y no sea un dolor de cabeza enorme para el desarrollador tratar de incorporar nuestras actualizaciones con partes de código obsoletas.

      Una vez clonado nuestro fork en nuestro equipo podemos ejecutar un <span class="command">git remote -v que nos mostrará los repositorios remotos a los que apunta nuestro “fork”

      Deberemos añadir un nuevo repositorio remoto “upstream” que será sincronizado con el fork, para ello ejecutamos lo siguiente (mutatis mutandis):

      <span class="command">git remote add upstream https://github.com/<em>usuario_original</em>/<em>repositorio_original</em&gt;.git

      Si volvemos a ejecutar un <span class="command">git remote -v veremos que ahora aparece el repositorio “upstream”.

      Hecho esto ahora deberemos “traer” los commits del repositorio original a nuestra copia. Dichos commits del repositorio se almacenarán en una rama separada llamada “upstream/master”.

      Es decir que en nuestro repositorio “forkeado” y clonado habrá una rama aparte en la que se irán acumulando las actualizaciones que se hagan en el repositorio original, y deberemos ir uniendo (“merge”) a la rama master de nuestro repositorio clonado, y hecho eso podremos ir modificándolo para hacer nuestros aportes.

      Pero por partes ¿Cómo se hace todo eso?

      Vayamos a nuestra rama master de nuestro repositorio “forkeado” mediante: <span class="command">git checkout master y nos dirá que hemos cambiado a la rama master.

      Desde nuestra rama ahora lo que queremos es “unir” las actualizaciones de repositorio original. Para eso deberemos utilizar el comando merge de git. Esto lo hacemos mediante: <span class="command">git merge upstream/master

      Por cierto, esto actualiza nuestra copia local del repositorio. Deberemos hacer un commit y push a nuestro fork para que estén de manera remota esos cambios actualizados.

      No soy un experto de git, lo utilizo sólo como “aficionado”, y voy aprendiendo sobre la marcha aquello que voy necesitando. Git es una gran herramienta con un montón de posibilidades y opciones. Espero que esta explicación te sirva…

      He tratado de explicar de manera sencilla lo que he aprendido hoy sobre git ¿Lo has entendido? Si mi explicación no ha sido muy clara, te dejo los enlaces de donde he sacado toda esta información para ver si así aclaramos conceptos…😉

      • https://help.github.com/articles/configuring-a-remote-for-a-fork/
      • https://help.github.com/articles/syncing-a-fork/

      Un par de enlaces adicionales para aprender algo más sobre las ramas o “branch” con las que podemos trabajar y utilizar en nuestros proyectos git:

      • Ramificaciones en Git – Procedimientos básicos para ramificar y fusionar
      • Ramificaciones en Git – Ramas Remotas

      ——————————————————————-

    3. File without filename could not get a thumbnail source.
      Crear “alias” de comandos de Git
      By victorhck from victorhckinthefreeworld

      Veamos como crear “alias” sencillos de los comando de Git que más utilizas, para ahorrar tiempo y trabajo.

      Este es un pequeño truco que acabo de aprender, y lo quería apuntar aqui en el blog, para que no se me olvide y para compartir con alguien más por si le sirve. Lo primero que hago cuando escribo sobre Git es aclarar que no soy ningún experto, soy un completo neófito, que sigue intentando aprender cómo funciona esta gran herramienta.

      En GNU/Linux lo que no existe se puede inventar, eso es lo bueno de poder hurgar tanto en las herramientas que utilizamos como en el propio sistema operativo.

      Digo esto porque con Git existen una serie de comandos para trabajar con él, pero estos se pueden ampliar, simplificar y potenciar por medio del uso de alias.

      • ¿Qué son los alias? son comandos creados por el usuario que con una sola palabra o mediante un comando sencillo realiza un comando más complejo, o una serie de acciones.
      • ¿Esto para que sirve? Pues principalmente para ahorrar trabajo a la hora de hacer tareas repetitivas, o para simplificar tareas

      Unos de los comandos que más utilizo son estos dos:

      ~\> git pull https://github.com/openSUSE/nombre_del_repo
      ~\> git push https://github.com/openSUSE/nombre_del_repo

      Bueno pues teclear esto cada vez puede ser un aburrimiento, aunque el atajo de Bash Ctrl+R me ahorra mucho tiempo. Pero hoy leyendo un buen libro sobre Git, aprendí a hacer unos alias para sustituir esos comando por estos dos:

      ~\> git actualiza
      ~\> git envia

      Para hacerlo puedes usar dos métodos:

      Desde la línea de comandos se pueden crear alias escribiendo este comando:

      ~\> git config --global alias.ci commit

      Esto significa que, por ejemplo, en vez de escribir git commit, simplemente necesitas escribir git ci.

      Pero para los dos alias que he creado yo este método no me funcionaba, así que edite el archivo .gitconfig que está en mi home y añadí estas líneas:

      [alias]
               actualiza = pull https://github.com/openSUSE/nombre_del_repo
               envia = push https://github.com/openSUSE/nombre_del_repo

      nota: en donde pone openSUSE/nombre_del_repo por supuesto hay que sustituir por el repositorio con el que estes trabajando! 😉

      Enlaces de interés

      • Libro sobre Git | http://victorhckinthefreeworld.wordpress.com/git-un-libro-para-conocerlo-y-manejarlo/
      • Consejos y trucos de Git | http://git-scm.com/book/es/Fundamentos-de-Git-Consejos-y-trucos
      • Git en wikipedia | http://es.wikipedia.org/wiki/Git

      —————————————————————————

    4. File without filename could not get a thumbnail source.
      Git y Github, tutorial básico de uso bajo GNU/Linux.
      By victorhck from victorhckinthefreeworld

      Pequeños apuntes del uso básico este software de control de versiones con Git. Cómo clonar un repositorio en nuestra máquina modificarlo y subir nuestros aportes al repositorio principal en Github.

      Lo primero aclarar que no soy un experto en Git, ni nada por el estilo. Estos son unos apuntes sencillos que he tomado y con los que trabajo. Simplemente utilizo un repositorio del equipo de diseño de openSUSE, con el que colaboro, que tienen alojado en GitHub,y en donde comparto mi trabajo. Lo primero dar las GRACIAS a quien se tomó la molestia de ayudarme en el canal IRC de openSUSE, y quien tuvo la paciencia de responder mis preguntas.

      ¿Que es Git?

      Git es un software para el control de versiones desarrollado en un principio por Linus Torvalds (sí, el creador del kernel Linux!) y se ha convertido en una herramienta indispensable para el desarrollo de software, incluido el propio kernel de Linux. Ya había otros programas que más o menos realizaban estas funcionas.

      Pero al señor Torvalds no le convencían, así que se aplicó el lema de GNU/Linux. si no existe siempre lo puedes crear. Y se puso manos a la obra y desarrolló este software. Y como es “lema de la casa” del creador del kernel Linux, es software abierto y colaborativo, por lo que el propio software de Git es desarrollado y mantenido por la comunidad en todo el mundo.

      ¿Cómo lo instalo?

      Para instalarlo en GNU/Linux, utiliza tu gestor de paquetes favorito, como estamos en openSUSE, abre Yast (o Zypper in git logueado como root desde la línea de comandos) y busca Git, e instalalo, junto con sus dependencias, así de simple!

      ¿Qué es GitHub?

      Esta web es un lugar donde nos proporcionan espacio para almacenar nuestros repositorios. Así no tienes que preocuparte de gestionar un servidor, etc. Ellos hacen el trabajo lo que resulta muy cómodo. Existen otras opciones como Gitorius, y otras. Pero hablaré de esta que es la que he utilizado.

      Para trabajar con repositorios de otros en los que colaborar con tu trabajo. Debes abrirte una cuenta en la página de GitHub. Rellenar un sencillo formulario y un certificado digital para que cuando subas material el servidor te identifique y autentifique que realmente eres quien dices ser. Esto es muy fácil, así que no lo explico, hasta yo lo conseguí hacer!! 😉

      Si vas a trabajar en repositorios de otros, como veremos en este ejemplo, es necesario que el mantenedor o encargado del repositorio te autorice a ti, a tu usuario de GitHub a escribir en el repo, de lo contrario sólo podrás leer, pero no podrías subir tus aportes, así que pídele derechos de lectura/escritura.

      ¿Cómo trabaja Git?

      Con Git puedes crear tu propio repositorio y trabajar en él. O puedes trabajar con el repositorio de otros, que será el caso que veamos. En este ejemplo que traigo al blog no es código de programa lo que veremos, ya que no soy programador. Si no un repositorio donde se almacenan diseños y creaciones para el artwork de openSUSE desarrollado por gente de todo el mundo. Pero eso nos es transparente. Da igual la naturaleza de los archivos que manejemos. En este caso trabajaremos sobre el repositorio principal, no haremos una rama propia, etc. Esto es sólo un primer acercamiento.

      A grandes rasgos.

      Clonaremos en nuestra máquina el repositorio original. Es decir Git descarga en tu equipo local, en tu PC de casa, todo el contenido del repositorio que se encuentra almacenado en GitHub. Es decir en tu equipo se creará una carpeta con todo el contenido idéntico a la que existe en el repositorio.

      Si ya lo tenías clonado de una vez anterior, ese paso no es necesario, así que nos saltaríamos esa parte, lo que haremos será actualizar la copia que tenemos en nuestro equipo local, para que descargue los nuevos aporte que hayan podido hacer otros usurios.

      Ahora que ya tienes las herramientas y los archivos que queremos, toca trabajar. Ya podemos realizar las modificaciones que queramos en los archivos que sea necesario, podremos crear nuevos archivos, o carpetas, etc…

      Realizado el trabajo le diremos a Git que añada y tenga en cuenta nuestros cambios, a los que etiquetaremos de alguna manera para identificarlos, y después los mandaremos al repositorio principal en GitHub donde quedarán almacenados y disponibles para que otros los puedan utilizar y modificar.

      Explicado así no parece muy difícil, verdad? Pues ahora iremos al meollo de la cuestión. Utilizaremos los comandos adecuados y verás que tampoco es algo difícil en la práctica.

      Comandos básicos.

      La forma de trabajo es desde la línea de comandos. Hay interfaces gráficas para realizar estos trabajos, pero desconozco su uso. Así que se note que eres un usuario de GNU/Linux de “pro”! Abre un terminal y teclea comandos! Hay algo mas bonito?? 😉

      Empezaremos clonando en nuestra máquina el repositorio que nos interesa alojado en GitHub, para ello utilizaremos el comando: git clone <dirección del repo>. Nos situaremos en un directorio donde queramos clonar el repositorio, en este caso crearemos uno llamado Git y dentro de este clonaremos el repo. En este caso tendrías que cambiar el nombre del repo, por aquel con el que quieras trabajar.

      victorhck@openSUSE:~\> mkdir Git
      victorhck@openSUSE:~\> cd Git
      victorhck@openSUSE:~/Git\> git clone https://github.com/nombre_de_repo/

      Dependiendo del tamaño del repositorio y de la calidad de nuestra conexión a Internet, tardará más o menos en descargarlo. Una vez finalizado el proceso ya tenemos los archivos del repositorio en nuestro PC. Este proceso de clonado sólo es necesario hacerlo la primera vez o si hemos borrado nuestra copia local del repositorio. Una vez clonado en nuestro equipo no es necesario volver a realizar este paso.

      Ahora vamos a actualizarlo. Despues de clonado no tiene mucho sentido actualizarlo, porque no debe haber ningún cambio como es lógico. Pero si ya teníamos nuestro repositorio clonado de una vez anterior debemos actualizar nuestra copia local del repositorio con los cambios que hayan hecho otros usuarios.

      Veamos como actualizar nuestra copia local del repositorio. Siempre trabajando desde el directorio donde lo tenemos descargado en nuesto equipo escribimos el siguiente comando: git pull <dirección del repo>

      victorhck@openSUSE:~/Git\> git pull https://github.com/nombre_de_repo/

      Dependiendo de la cantidad de modificaciones hechas por otros tardará más o menos en actualizar nuestra copia local. Una vez terminado ya podemos hacer los cambios que queramos o sean necesarios. En nuestro ejemplo imaginemos que hemos creado una nueva carpeta llamada Traducciones y dentro un archivo de texto llamado Español.txt (por ejemplo…)

      Bien hecho esto veamos cuales son los cambios pendientes con el siguiente comando: git status

      victorhck@openSUSE:~/Git\> git status

      Y veremos que nos presenta los cambios que hemos hecho. En nuestro ejemplo nos dirá que hemos creado una carpeta y añadido un nuevo archivo.

      Para que tenga en cuenta nuestros cambios le diremos que los añada al repo con el siguiente comando git add .  (Sí, el punto también forma parte del comando!!)

      victorhck@openSUSE:~/Git\> git add .

      Ahora etiquetaremos estos cambios. Esto es útil para saber qué es lo que se ha hecho. Un pequeño comentario para explicar la naturaleza de la modificación, esto se especifíca mediante este comando: git commit -m “comentario” -a  Debemos poner los modificadores -m y -a para que se etiqueten así a todos los cambios.

      victorhck@openSUSE:~/Git\> git commit -m "Creada carpeta de traducciones y añadida la española" -a

      Hasta ahora hemos dicho a Git  que tenemos cambios, que vamos a añadir, pero estos no han salido de nuestra máquina, así que sólo estan aplicados en local. Ahora debemos lanzarlos y decirle a Git que los añada al repositorio en GitHub y así esten disponibles para todos. Esto se hace mediante el comando git push <dirección del repo>

      victorhck@openSUSE:~/Git\> git push https://github.com/nombre_de_repo/

      Se pide autentificación del usuario, metes tu nombre de usuario y contraseña y si tienes derechos de escritura en el repo, git subirá tus cambios, y la copia en el servidor de GitHub tendrá tus cambios disponibles para todos!

      Despues de eso si no quieres almacenar la copia del repositorio local en tu PC para no utilizar espacio en el disco duro la puedes borrar. Y la próxima vez que quieras volver a trabajar con el repositorio tendrás que volver a clonarlo. Si no lo borras, antes de trabajar y hacer tus cambios debes actualizar tu copia local para asegurarte que estas trabajando con lo último y más actualizado disponible en el repositorio.

      —

      Espero que te sirva como primera guía este tutorial. Git es una herramienta mucho más potente que esto que te he mostrado aqui. Estos son simplemente mis apuntes, que expongo aqui por si sirven a alguien más, si es así me alegro!! Por último te dejo algunas direcciones y un vídeo muy bueno que he encontrado para aclarar más los conceptos.

      Enlaces de Interés:

      • Página ofial de Git | http://git-scm.com/
      • Página oficial de GitHub | https://github.com/
      • Git en Wikipedia | http://es.wikipedia.org/wiki/Git

      Este vídeo es de Fran Moreno Puedes visitar su página y ver todo el material interesante que tiene: http://www.franmoreno.com/

      Además desde la web Cyberhades nos ofrecen una amplia lista de videotutoriales sobre Git. Podéis encontrarla en este enlace:

      • http://www.cyberhades.com/2013/10/17/video-tutoriales-para-aprender-git/

      —————————————————————

    5. File without filename could not get a thumbnail source.
      Git: modificar el texto de un commit
      By victorhck from victorhckinthefreeworld

      Tutorial de cómo modificar el texto de un commit que hayamos realizado.

       

      Estás utilizando git y te acabas de dar cuenta que has hecho un “commit” añadiendo en el texto algo erróneo, algo que no debías poner o has cometido un error. ¿Se puede solucionar? Claro que sí. Veamos cómo modificar el texto de ese “commit” para añadir, quitar o modificar aquello que hemos hecho mal.

      Hoy acabo de hacer un commit en un repositorio, y me han dicho que muy bien, pero que el texto del commit por favor lo pusiera en inglés. Así que he estado mirando cómo hacer esto, y lo aprendido lo comparto por aquí para futuras consultas y para compartirlo contigo, paciente lector, por si te interesa.

      Voy a plantear dos situaciones posibles. Y para realizar las tareas utilizaremos la línea de comandos que sin duda es la gran herramienta para el manejo de repositorios, por encima de cualquier GUI gráfica.

      A.- Has realizado un commit que todavía no has subido al repositorio.

      Es decir realizando tu tarea has realizado un commit, pero no has hecho push al repositorio, por tanto sigue estando en tu repositorio local. Para ello utilizaremos el comando: git commit --amend

      1. Vamos hasta nuestro repositorio que contiene el commit que queremos modificar.
      2. Escribimos git commit --amend y pulsamos Enter.
      3. Se abre un editor de texto donde podrás modificar el mensaje del commit, y después deberemos guardar y cerrar.

      Hecho esto, la próxima vez que realicemos un push al repositorio veremos que el texto de nuestro commit ha cambiado. Por cierto a mí me abrió el editor VI para modificar el texto, recordar que para guardar el texto deberemos: pulsar Esc, y después :wq para escribir los cambios (w=write) y salir (q=quit).

      Podéis cambiar el editor de texto que queráis que utilice git cambiando la configuración mediante este comando, para cambiarlo por emacs si es vuestra elección:

      git config --global core.editor emacs

      B.- Has realizado un commit que ya has subido al repositorio.

      Ahora imaginemos que ya has realizado el commit, que no te diste cuenta que había un error o algo erróneo en el texto del commit, y que ya hiciste push al repositorio de tu copia local. Y alguien te dice: “oye, cambia el texto del commit”. Bueno, pues veamos qué hacer.

      1. Deberemos seguir los tres pasos anteriores del caso A.
      2. Deberemos forzar un push para que sobreescriba el anterior commit, con el comando:
        git push --force 

      Cuidado con el uso de push forzado, si hay más usuarios que tienen clonado el repositorio, puede causar problemas. También existe la posibilidad de modificar commits anteriores o varios commits a la vez. Pero eso ya no quiero incluirlo en este artículo.

      La documentación para realizar esto, lo he sacado de este enlace, por si quiere consultarlo:

      • https://help.github.com/articles/changing-a-commit-message/

      Espero que os haya resultado útil el mini-tutorial, y os ayude en vuestros trabajos utilizando Git. He escrito más tutoriales para dummies como yo sobre git que puedes encontrar en este enlace:

      • https://victorhckinthefreeworld.com/tag/git/

      —————————————-

Feeds

  • Activity Streams
  • Atom
  • Help
  • About
  • FAQ
  • Privacy
  • Source
  • Version
  • Contact

Quitter España is a social network. It runs on GNU social, version 1.2.0-beta5, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All Quitter España content and data are available under the Creative Commons Attribution 3.0 license.