Otros

otros temas

En está categoría pondremos aquellos aportes queremos publicar y que no encajan en ninguna otras sección de la Web.

Temas relacionados con la tecnólogia y que ademas pueden ser de interes para más personas a aparte de a nosotros.

Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado

GITHUB

Es una plataforma de desarrollo colaborativo sobretodo para aquellos que utilizamos GIT, recordar la utilización GITHUB gratuito tiene que ser proyecto codigo abierto y están publicos. La plataforma te ofrece este mismos servicio pero privado, lógicamente de pago.

- Permite subir los proyectos publicos los queramos pero de open source.

- Permite subir proyectos privados pero de pago

- Puede tener un wiki por cada proyecto.

 ¿ Lo primero que hacer en GitHub ?

Identificarte ( loguearse )  en la web github con tu usuario y contraseña, si no tiene crear una cuenta, son bastante respectuoso con tu cuenta email y no te molestan con emails.

Empezar con algún proyecto ( REPOSITORIO)

Puedes empezar con:

  • Repositorio nuevo: Nuestro propio proyecto
    • NO TENEMOS UN REPOSITORIO LOCAL CREADO.
    • TIENE UN REPOSITORIO LOCAL CREADO
  • FORK de repositorio de otro usuario: Queremos trabajar en un proyecto de otro usuario de github
    • VER DIFERENCIAS ENTRE FORK Y EL REPOSITORIO ORIGINAL

REPOSITORIO NUEVO DE UN PROYECTO.

 El Repositorio nuevo podemos crearlo directamente desde la interfa de GITHUB , pero antes de realizarlo debemos tener en cuenta.

"Initialize this repository with a README" , si lo marcamos con [si] o [no]

Github2

 [si] -> Si vamos hacer un git clone (vacío)
 [no]-> Si ya tiene git init en tu proyecto y quieres enviar todos tus commits.

A la hora querer crear un repositorio nuevo en Github puede surgir varias situaciones:

  • NO TENEMOS UN REPOSITORIO LOCAL CREADO opción [si]: Si aun no tiene repositorios local creado , aunque tenga ya tu código , pero no tenemos git init.
  • TIENE UN REPOSITORIO LOCAL CREADO opción [no]: Que ya tengas un repositorio local en git y ahora quieres compartirlo en GITHUB, con los commits que ya realizaste. (compartir tu repositorio local completamente )

 Explicamos las dos situaciones.

NO TENEMOS UN REPOSITORIO LOCAL CREADO.

Si no tenemos o no queremos subir los comits de un repositorio local y pulsamos [si] en "Initialize this repository with a README" a la hora crear el REPOSITORIO EN GIHUB una forma sencilla sería:

En el directorio raiz donde queremos situar nuestro repositorio ( en nuevo directorio), con la siguiente instrucción nos crea el repositorio en local, creando un directorio con el nombre del repositorio que creamos con anterioridad en github.

git clone https://  #que nos indica el repositorio github recien creado.

Entonces nos crea una directorio con el nombre del proyecto ( que estará vacio), ya que lo tenemos vacio, pero con el repositorio local de git ( .git ), y configurado el repositorio remoto (GITHUB) como origin.

A partir ahí, ya podemos añadir nuestro código en ese directorio y empezar commitar ...

git commit -m "Inicio en servidor local"

Una vez tengamos tengamos comitado en nuestro repositorio local, ya podemos enviar al repositorio REMOTO de github con la instrucción git push.

git push origin

Todo ha ido correcto y te pedirá [usuario] y [contraseña] de Github para subir tu repositorio local con nuestro comits al repositorio remoto de GITHUB.

Todo esto si hemos selecciona [si] en "Initialize this repository with a README"

Si has pulsado [no] simplemente tiene que configurar el git remoto de tu REPOSITORIO LOCAL con:

git remote add origin http// # repositorio clonado

Con la instrucción anterior indicamos que el repositorio remoto es ....

Si todo fue correcto, solo te faltaría enviar REPOSITORIO LOCAL al REMOTO, para ello con el comando push con los siguientes parametros.

git push origin master -u

Nos pidirá el usuario y la contraseña y listo repositorio remoto actualizados.

 

TIENE UN REPOSITORIO LOCAL CREADO

Al tener un repositorio local creado para poder enviarlo a un REPOSITORIO REMOTO con todos los commits, a un repositorios REMOTO creado en GIHUB sin haber marcado [no] "Iniciatize this repository with a Readme".

Lo que debe hacer es indicar a tu repositorio local la dirección del repositorio remoto (vacio) que acaba de crear, con la siguiente instrucción:

git remote add origin https://urldelrepositorionuevo 

- nos pondrá la url en remote origin.....

Si fue todo correcto, nos queda hacer push origin ,aunque con par de parametros más:

push origin --force

Instrucción que parece bastante peligrosa utilizar, según veo la red. (link)

Nos pedirá [usuario ] y  [ contraseña] de repositorio remote, luego añade el repositorio local en el repositorio remote.

Te en cuenta que todos los commits de nuestro REPOSITORIO LOCAL. Apartir de es primer push, ya el resto no necesitamos utilizar la opción --force.

 TRABAJA EN COLABORACIÓN:

Se podría hacer directamente desde el repositorio del usuario, pero los cambios que realicemos no podremos enviarlo sin que el usuario nos de acceso a su REPOSITORIO REMOTO, cosa que dudo, salvo que haya mucha confianza entre vosotros.

HACER UN FORK DE REPOSITORIO DE OTRO USUARIO:

Si lo queremos es realizar cambien en un proyecto de otro usuario, lo ideal es hacer FORK en GITHUB , ya que asi podemos realizar un pull requests al CREADOR y este mezclarlo con el suyo si le interesa nuestros campos

 Realizar un FORK en GITHUB es tan sencillo como pulsando FORK desde el repositorio queremos.

Una vez realizado FORK , en nuestro nuevo repositorio simplemente tenemos clonar el repositorio a local como indicamos en apartado anterior, sin volver a crearlo claro.

git clone https://  #que nos indica el repositorio remote que hicimos fork.

 Recuerda que la dirección sera algo así: gihub.com/tuusuario/nombrerepositorio

A partir ahí tenemos el repositorio con los commits que haya hasta ahora.

Si realizamos cambios y queremos trabajaremos en nuestro repositorio (FORK) sin entorpecer al usuario u organizacion del proyecto original.

Una vez queramos enviarle o recomendarle un cambio al usuario o organización podemos realizarlo con un push request, donde el usuario o organización decidirá si quiere los aplicar los cambios o  no.

Una vez lo acepten a ti llegará una notificación que fue aceptado o rechazado.

MANTENER AL DIA NUESTRO FORK

Si mantener al dia nuestro fork y actualizado con el repositorio original, si queremos ver las diferencias entre uno u otro.

Lo primero que debemos hacer es crear una conexion al REPOSITORIO ORIGINAL ( el que hicimos el fork) es muy sencillo con la instrucción:

git remote add nombreconexion http://ruta repositorio original

En nombre conexión podremos el queramos, menos origin, ya origin por normalmente ya lo utilizamos con anterioridad al realizar conexion al fork.

NOTA: Al hacer un fork en gihub , al hacer remote add , ya sabe cual la direccion del del repositorio original, sino lo hubieramos hecho un fork , ya sería otro cantar... :-) , por lo que no sería necesario poner la ruta.

Con la siguiente instrucción vemos las conexiones remotas que tenemos en nuestro repositorio local. Instruccion para ver conexiones remotas:

git branch -a

Nos mostrará las conexiones que tenemos creadas, algo así:

* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
remotes/nombreconexion/master

Luego simplemente ya podemos utilizar instrucciones git para ver log, differencias que hay en el repositorio original ( del que hizimos el fork).

 Ejemplo de instrucciones a utilizar:

git log nombreconexion/master
git diff nombreconexion/master

Te en cuenta que esto solo vemos las diferencias que hay en el momento de realizar la conexión, si ya paso tiempo, debes actualizar esos datos de la conexión.

Si quieres actualizar ese repositorio con las siguiente instrucción:

git fetch nombreconexion

Entonces ya tiene actualizado el REPOSITORIO REMOTO que le indicaste y ya puede ver los logs o differencias hay.

Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado

GIT DIFF

DEFINICIÓN:

Muestra los cambios en los ficheros desde donde quereamos hasta donde queramos en el arbol de trabajo ( la línea de tiempo de trabajo).

SINOPSIS

git diff [options] [<commit>] [--] [<path>…​]
git diff [options] --cached [<commit>] [--] [<path>…​]
git diff [options] <commit> <commit> [--] [<path>…​]
git diff [options] <blob> <blob>
git diff [options] [--no-index] [--] <path> <path>

OPCIONES:

 Información recopilada principalmente de http://git-scm.com/docs/git-diff

git diff [--options] [--] [ ...]

Con el anterior esquema podemos ver los cambios que han realizado en relación con el índice (zona de espera para la próxima confirmación). En definitiva, ver las diferencias, pero no solo las que esperan confirmación sino con otros puntos, branch o incluso con resositorio remotos.

Ejemplos

Pondremos ejemplos practicos.

Ver cambios que acabamos de realizar en un fichero

En nuestro repositorio tenemos index.php y queremos ver los cambios que hemos realizado y aun no lo comitamos ni preparados para comitear.

git diff index.php

 Nos muestra por la terminal los cambios que realizamos en ese fichero con respecto al HEAD de nuestro repositorio local.

Ver cambios de un fichero cuando ya lo añadimos (add) y esta preparado para commit.

La instruccion en este caso tenermos que ponerle la opcion --cached

git diff --cached index.php

 

Ver cambios en un fichero con respecto a otra rama

Si tenemos dos ramas en repositorio local, una desarrollo y otra produccion, entonces queremos saber que cambios realizamos en un fichero determinado de la rama de desarrollo con respecto a producción.

git diff RamaDesarrollo RamaProduccion /rutaFichero

Nos muestra por terminal la diferencia de los ficheros.

Ver que ficheros cambiaron entre esas ramas.

Es similar a lo anterior, pero no es lo mismo, lo que pretendemos es que nos liste solo los ficheros que cambiaron entre las dos ramas.

git diff --name-status RamaDesarrollo RamaProduccion

Nos va indicar aquellos modificados (M) , añadidos (A) o incluso aquellos movidos...  Rnumero.. pero no estoy seguro... :-)

Git diff - Cambian permisos

Cuando cambiamos permisos a un fichero dentro un repositorio git este detecta que se cambio y lo marca como modificado. Al hacer git diff, nos indica los permisos que tenía y que tiene ahora.

Esto puede ser muy buenos para controlar que no nos cambien los permisos de nuestro proyecto si nuestro control, pero también se puede convertir en un incordió.

Se puede convertir en incordió cuando trabajamos con un proyecto en servidores que necesitan otro tipo de permisos de los que nosotros ponermos habitualmente en nuestros servidores, para ello preguntamos como lo podemos evitar.

Nuetros crack @Guillermo no pasas el siguiente comando.

git diff --summary master | grep -v 'mode change'

El grep lo que hace es descartar 'mode change'.

De esta forma ya no tiene en cuenta los cambios de permisos.

Trabajar con windows y linux en el mismo proyecto.

Esto realmente puede convertirse en una agonía, ya que windows el salto de carro lo marca con M$ y linus solo $, esto hace que si cambiamos el fichero con windows, nos va decir que tenemos diferencias en todo el fichero.

Al hacer git diff del fichero, no sabemos porque hay diferencias, ya marca borrado todo el fichero y en verde todo el fichero.

Si vemos el fichero y version anterior con un editor grafico no vemos diferencias. Nosotros por ejemplo utilizamos diffuse

diffuse -r fichero

Cuando nos sucede esto, ya pensamos en eso y entonces le indicamos al editor que marque los saltos de carro...

Una forma  rapida de ver los saltos de carros con la instruccion :

cat -A fichero

Nos muestra el salto de carro.

Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado

¿ Qué es Git ?

logo-git

Git es un software de control de versiones creado y diseñado por Linux en 2005, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente.

¡ Hasta entonces Linux utilizaba un controlador de versiones privativo !.. extraño

¿Cómo empezar con Git o un Control de Versiones?

Personalmente quiero deciros que la única forma de empezar con Git es poniendose, no es tan dificil como parece, si empezamos a utilizarlo nos daremos cuenta que es muy útil e incluso se vuelve indispendable para trabajar.

Nosotros llevabamos años pensando en utilizarlo, por pereza y la verdad ahora nos arrepentimos, por el tiempo perdido. En está web tenemos un post " Instrucciones Básica de Git "  que os puede ayudar, un post que utilizamos para ir anotando como instalamos, como instrucciones que fuimos necesitando al empezar.

Hoy en día asesoramos a otros como implatar git como gestor contenido, en cualquier sistema operativo, como utilizarlo en cualquier proyecto, ya que consideramos que es una herramienta fundamental.

Vídeos , links y anotaciones de taller a los que fuímos.

Ahora insertamos en nuestra web , un vídeo que nos facilita Galpon lleva años realizando talleres sobre Git,en esta caso uno de una serie de talleres Symfony , explicaron de una forma bastante amena el uso de Git.

Video de taller realizado en 2011 por Nacho Martín.

En este año, Galpon organizo otro taller de GIT en Altamar en el que Jesús Amieiro nos explico como inicianor en git. En la web de Jesús Amiero nos deja dos documentos de utilidad para el taller y poderse iniciarse en este controlador de versiones.

Esos documentos los guardamos en está web para tenerlos siempre a mano,Presentación y Guión de comandos a utilizar

En esos documentos del Taller trato los siguiente puntos:

  • ¿Que son los Sistemas de Control de Versiones (CVS)?
  • Arquitectura de los Sistemas de Control de Versiones (CVS).
  • Git. Origen y características.
  • Instalación en los S.O. máis frecuentes.
  • Configuración inicial.
  • Uso da ayuda.
  • Inicialización y clonado de un repositorio.
  • Gestionando los cambios de un proxecto con Git.
  • Deshaciendo los cambios.
  • Ignorando archivos.
  • Navegando por los commits.
  • Ramas: creación, cambio, fusión, borrado.
  • Guardando de forma provisional.
  • Ejercicio práctico.

Más lugares y Links con más información sobre Git

Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado

Instalación de Git en los distintos sistemas operativos

Os mentí en subtitulo !!
No voy indicaros como instalar en más sistemas operativo que en Linux y en terminal, ya que es el utilizo.  :-)

apt-get install git

Cuando vaya necesitando instalar en otros sistemas operativos, os lo pondré.

Es tan facil desde terminal que da mucha pereza.

Con la instrucción anterior es suficiente para tener todo listo para iniciar tu primer repositorio local con Git.

Inicializar repositorio local

Inicio desactivadoInicio desactivadoInicio desactivadoInicio desactivadoInicio desactivado

Hace años que tengo un canal personal en youtube, donde subo de todo al canal. Hace años cobraba un comisión muy pequeña en Youtube por la publicidad que ponían en esos videos.

En aquel momento Youtube podíamos se parnet sin ningún minimo. Ahora desde hace un par de años el programa Parnet es un poco mas exigente:

Descripción general del Programa para Partners de YouTube

Tiene que solicitar añadirte al programa Partners de YouTube y debes cumplir estos requisitos:

  • Que en tu pais el programa para Partners de YouTube esté disponible ( España SI).
  • Que durante los ultimos 12 meses se vierna más de 4000 horas de videos de tu canal.
  • Tener más de 1000 suscriptores.
  • Crear contenido que cumpla las políticas del Programa para Partners de YouTube.
  • Tener asociada una cuenta aprobada de AdSense.

Lo que dice Youtube es que con este umbral en el programa de parnets de Youtube identifican a los creadores que realmente aportan cosas positivas a la comunidad, y los otros usuarios no se lucren del programa.

Ver mas informacion en https://support.google.com/youtube/answer/72851#eligibility