Archive for Desarrollo web

noviembre 19th 2017

Manejo de ramas de desarrollo con git

Número de lecturas: 334
{lang: 'es-419'}

Git es un sistema de control de revisiones distribuido amparado por la GPLv2 que enfatiza sobre todo la velocidad. Fue diseñado y desarrollado inicialmente por Linus Torvalds, creador de Linux como proyecto para mantener repositorios del kernel de Linux.

Cada directorio de trabajo git es un repositorio completamente funcional y con total capacidad independientemente de si existe acceso a la red y de un servidor centralizado, lo cual lo convierte en una poderosa herramienta tanto para el desarrollo de grupos de trabajo como para el desarrollo individual.

Git dispone de muchas características pero hoy voy a hablaros del manejo de ramas de desarrollo con git. Si estáis familiarizados con Github sabréis que la base de dicha red social de desarrollo es el “fork“ de ramas de desarrollo y su posterior “merge“. Git es treméndamente eficiente en ese aspecto.

Git Branching

El manejo de ramas o branching es la parte más atractiva y divertida de trabajar con Git. Cuando inicializamos o clonamos un repositorio, siempre obtenemos una rama principal por defecto llamada master a no ser que especifiquemos lo contrario.

Cambiando de rama

Supongamos que estamos trabajando en un proyecto y queremos añadir nueva funcionalidad al mismo. La forma adecuada de hacerlo con Git es crear una nueva rama con el nombre de la nueva funcionalidad donde añadiremos nuestros cambios y después cambiaremos a ella (git branch switching).

$ git branch nuevafuncionalidad
$ git checkout nuevafuncionalidad

Existe un atajo para crear una rama que aún no existe usando directamente el comando checkout que consiste en pasar el parámetro -b en la llamada.

$ git checkout -b nuevafuncionalidad

Una vez creada nuestra nueva rama de desarrollo, podemos comprobar en que rama nos encontramos utilizando el comando git branch

$ git branch
master
* nuevafuncionalidad

En el ejemplo anterior podemos ver como nos encontramos en la rama nuevafuncionalidad. Esto significa que si modificamos, borramos o añadimos archivos, ésta incluirá esos cambios pero no así la rama master. Supongamos que hemos añadido la nueva funcionalidad y hemos modificado un par de archivos. Vamos a hacer un commit.

$ git commit -a -m 'añadida nueva funcionalidad chula chula de la ostia'
Created commit: a6b18c4: añadida nueva funcionalidad chula chula de la ostia
  2 files changed, 6 insertions(+), 0 deletions (-)

Ahora tenemos que hacer un cambio en un archivo de la rama master para arreglar un bug que nos han reportado la gente que está testeando esa rama y debemos corregirlo de manera inmediata para que puedan seguir con su trabajo. Podemos volver a la rama master y añadir allí los cambios sin preocuparnos de posibles inconsistencias con nuestra nueva rama nuevafuncionalidad

$ git checkout master
$ git commit -a -m 'arreglado el bug #00002345'
Created commit b89ae56: arreglado el bug #00002345
 1 files changed, 1 insertions(+), 1 deletions(-)

Ahora podemos ver las diferencias entre nuestras dos ramas usando el comando diff.

git diff --stat master nuevafuncionalidad
deliverance.py                      |      4 ++--
lib/nuevafuncionalidad.py           |      4 ++++
lib/test/test_nuevafuncionalidad.py |      4 ++++
3 files changed, 7 insertions(+), 2 deletions(-)

Además podemos crear un parche para aplicar uno al otro pero lo que realmente querremos hacer es mezclar ambas ramas, lo que se conoce como un branch merging

Mezclando Ramas

Hemos testeado profundamente nuestra nueva funcionalidad y estamos listos para moverla de la rama nuevafuncionalidad a la rama principal master. Dicha acción requiere que mezclemos el contenido de una de las ramas dentro de la otra, esto es lo que en Github llaman “Solicitud de Pull“ (realmente en Github lo que se hace es un git rebase pero esa funcionalidad la trataremos otro día).

Para realizar la mezcla de la rama nuevafuncionalidad dentro de master vamos a situarnos en la rama mater y a mezclar ambas:

$ git checkout master
$ git merge nuevafuncionalidad

Como veis esto es cualquier cosa menos traumática, realmente es muy sencillo mezclar ramas en Git. Una vez hemos mezclado nuestras ramas, y en caso de que no haya conflictos, podemos eliminar la rama nuevafuncionalidad por que no vamos a necesitarla más.

$ git branch -d nuevafuncionalidad

Resolviendo conflictos

¿Qué pasa si editamos el mismo archivo en ambas ramas y sobre las mismas líneas?. Pues que se generará un conflicto que tendremos que resolver a mano por que Git aunque es útil y potente, no tiene la capacidad de decidir que versión del código en conflicto es la correcta.

Imagina que hemos modificado el archivo deliverance.py en ambas ramas en las mismas líneas. Git generará un conflicto a la hora de la mezcla y siguiendo su política de no intrusión nos solicitará resolver el conflicto de manera manual.

$ git merge otrarama
Auto-merged deliverance.py
CONFLICT (content): Merge conflict in deliverance.py
Automatic merge failed; fix conflcits and then commit the result.

Como se puede apreciar, Git nos ofrece toda la información relevante para solucionar el conflicto y realizar un nuevo commit. El archivo problemático en este caso es deliverance.py.

    def send_delivery_request(request):
        self._server.request = request
< <<<<<< HEAD:deliverance.py
        self._rtime = 6000
===
        self._rtime = get_time_to_live(request)
>>>>>>> otrarama:deliverance.py
        # Send the request to the service
        self._server.send(self._rtime)

Podemos ver como hay un conflicto entre una y otra versión, mientras que en la rama principal se utiliza un valor hardcoded como tiempo máximo de respuesta, en el código de la rama otrarama se utiliza una función que devuelve un valor en base al request. Debemos de solucionar el problema y realizar un nuevo commit.

    def send_delivery_request(request):
        self._server.request = request
        self._rtime = get_time_to_live(request)
        # Send the request to the service
        self._server.send(self._rtime)
$ git add deliverance.py
$ git commit -m 'solucionando conflictos'
Created commit 17c688a: solucionando conflicto

Deshacer un Merge

En ocasiones veo muertos… no en serio. En ocasiones, querremos deshacer un merge por que la habremos cagado nosotros o otra gente de nuestro equipo de mala manera y encontraremos muchos conflictos a la hora de intentar seguir mezclando ramas o de trabajar normalmente. En esas ocasiones querremos deshacer de forma total el entuerto.

Git viene al rescate con el comando reset. Para hacer un reset de nuestro directorio de trabajo y volver atrás hasta antes de intentar mezclar las ramas, solamente debemos de ejecutar a nuestro buen amigo git reset.

$ git reset --hard HEAD

El parámetro --hard se asegura de que tanto nuestro índice de archivos como el directorio de trabajo cambien para que coincidan con lo que era antes del merge. Por defecto solo se restablece el índice, dejando los archivos parcialmente mezclados en el directorio de trabajo.

Si por casualidad has hecho un cambio y después de hacer un commit has decidido que era un error por que tus tests unitarios han empezado a romperse en mil pedazos (por ejemplo), aun puedes ir atrás y deshacer ese commit usando también reset.

$ git reset --head ORIG_HEAD

Esto es solo útil si lo que quieres es deshacer solo el último cambio. Si lo que quieres es deshacer un commit anterior a ese, entonces debes utilizar la herramienta revert que es un poco peligrosa y se aleja bastante del cometido de este post.

Conclusión

Git nos ofrece una forma sencilla de trabajar con ramas de desarrollo en nuestros proyectos. Y esto es solo la punta del Iceberg, Git nos ofrece otras funcionalidades como el stashing o el rebase de las que hablaremos en próximos artículos. Hasta entonces, ¡saludos y buen code merging!

Más Información | git revert, git rebase

Fuente:

genbeta.com

noviembre 1st 2017

¿Cómo eliminar un repositorio de Git creado con ‘git init’ en un directorio?

Número de lecturas: 2608
{lang: 'es-419'}

Git guarda todos los cambios realizados en el directorio .git de la carpeta donde se el repositorio. Para eliminarlo simplemente hay que borrar esa carpeta.

cd carpeta/
rm -rf .git

Documentación de Git: http://git-scm.com/documentation

Fuente:

http://polemicus.com

octubre 20th 2017

“Error” PHP Notice: Undefined property: stdClass::$

Número de lecturas: 2042
{lang: 'es-419'}

Este “error” es mas bien un aviso, que nos alerta que por ejemplo existe una variable que no tiene información o alguna, que tengas en cuenta que hay una propiedad que la clase no tiene o que no esta definida.

Cuando nos muestre este error el código se seguira ejecutando pero se debe corregirlo con un if para validar o colocando antes de la variable el simbolo @ con esto lo solucionamos.

En frameworks como Symfony en el ambiente de desarrollo para la ejecución y nos alerta pero en el ambiente de producción no muestra el aviso.

Ejemplo de solución:

@$datosCliente = $decode->datosCliente;

 

octubre 19th 2017

Cómo se puede cambiar la clase CSS de un elemento mediante JavaScript

Número de lecturas: 1327
{lang: 'es-419'}

Realizar esta acción es sencilla utilizando classList entonces en una parte del código un elemento puede tener una característica definida por la clase y según alguna acción ya no tenga la misma.

// añadir una clase
document.getElementById("boton").classList.add('clase_css');
// eliminar la clase indicada
document.getElementById("boton").classList.remove('clase_css');