En el momento de escribir esta entrada sigo sin haberme "sumergido" realmente en Symfony2. He estado aprendiendo a manejar herramientas (xDebug, NetBeans, Twig, etc) para mejorar mi entorno de trabajo, y conocer recursos utilizados habitualmente en Symfony. Todo para intentar abordar el famoso framework con la mejor preparación posible.
De todas formas, antes de seguir adelante he querido echar un vistazo a la posibilidad de, con un único proyecto de Symfony, gestionar el contenido de varios dominios. De hecho es uno de mis objetivos más importantes. Por lo pronto he encontrado dos enlaces que, aunque no son de Symfony2 sino de su predecesor, quiero "guardar" en esta entrada para analizarlos con calma en cuanto pueda.
http://www.programania.net/diseno-de-software/un-proyecto-multiples-dominios-con-symfony-1-4-y-propel-1-5/
http://mirmodynamics.com/post/2008/12/22/Multiple-domains-for-one-symfony-project,-the-basics
Espero poder comentarlos en breve...
jueves, 31 de marzo de 2011
sábado, 19 de marzo de 2011
Configurar Xdebug en NetBeans
Si ya hemos instalado Xdebug en nuestro PHP (más información aquí) seguramente nos faltará un paso para utilizarlo de forma integrada en NetBeans. Para comprobarlo basta con acceder a la opción "Depurar"->"Debug Proyect" con un proyecto PHP abierto tal y como se muestra a continuación:
Si no tenemos Xdebug configurado para trabajar desde NetBeans, en la parte inferior derecha aparecerá una barra de progreso como la siguiente:
Que permanecerá durante mucho tiempo moviéndose sin ningún resultado. Mejor interrumpirlo con el botón que aparece a la derecha de la barra. Entonces, nos aparecerán indicaciones sobre los pasos que tenemos que seguir. Se trata de un mensaje como este:
Así que, en definitiva, lo que tenemos que hacer es añadir a nuestro php.ini las siguientes líneas:
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost (o la ip del servidor Web)
xdebug.remote_port=9000
Luego, como siempre que hacemos cambios en el php.ini hay que reiniciar Apache para que la nueva configuración surta efecto.
Pequeño contratiempo
Una vez hecho todo lo anterior, al iniciar de nuevo la depuración desde NetBeans me he encontrado con un mensaje como el siguiente:
Para solucionarlo he dicho que sí y he indicado el puerto 9001 en el campo "Debugger Port" de la ventana que se abre y a la que también se puede acceder desde "Herramientas"->"Opciones"->"PHP".
Luego he hecho lo mismo en el php.ini (xdebug.remote_port=9001) y he reiniciado Apache. Ahora ya todo funciona a la perfección.
En esta página hay documentación detallada y oficial de NetBeans sobre cómo configurar Xdebug.
Si no tenemos Xdebug configurado para trabajar desde NetBeans, en la parte inferior derecha aparecerá una barra de progreso como la siguiente:
Que permanecerá durante mucho tiempo moviéndose sin ningún resultado. Mejor interrumpirlo con el botón que aparece a la derecha de la barra. Entonces, nos aparecerán indicaciones sobre los pasos que tenemos que seguir. Se trata de un mensaje como este:
Así que, en definitiva, lo que tenemos que hacer es añadir a nuestro php.ini las siguientes líneas:
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost (o la ip del servidor Web)
xdebug.remote_port=9000
Luego, como siempre que hacemos cambios en el php.ini hay que reiniciar Apache para que la nueva configuración surta efecto.
Pequeño contratiempo
Una vez hecho todo lo anterior, al iniciar de nuevo la depuración desde NetBeans me he encontrado con un mensaje como el siguiente:
Para solucionarlo he dicho que sí y he indicado el puerto 9001 en el campo "Debugger Port" de la ventana que se abre y a la que también se puede acceder desde "Herramientas"->"Opciones"->"PHP".
Luego he hecho lo mismo en el php.ini (xdebug.remote_port=9001) y he reiniciado Apache. Ahora ya todo funciona a la perfección.
En esta página hay documentación detallada y oficial de NetBeans sobre cómo configurar Xdebug.
¿Qué es Xdebug?
Xdebug es una extensión para PHP que proporciona un soporte muy completo para la depuración de nuestros scripts. Enumeramos continuación sus características principales:
- Añade características avanzadas en el volcado del valor de las variables, al sobreescribir la función de PHP var_dump().
- Las trazas de error incluyen información personalizable, y son lanzadas automáticamente cuando PHP genera un mensaje a nivel de warning, error o info.
- Permite hacer trazas personalizables de funciones: invocaciones, valor y tipos de parámetros y valores de retorno.
- Incluye un analizador de cobertura de código. No sólo es útil para posibles detecciones de código inaccesible sino también para conocer el alcance de nuestros test unitarios.
- Hacer análisis de rendimiento. Detectar cuellos de botella, tiempos muertos, carga de recursos y en general, el comportamiento de nuestros script PHP con la información manejada en tiempo de ejecución. La información generada por el profiles puede ser posteriormente analizada visualmente con las aplicaciones opensource y GPL KCacheGrind (linux+KDE), o WinCacheGrind (Windows).
- Añade la posibilidad de depuración a cualquier cliente que sea capaz de ejecutar scripts PHP y soporte el protocolo DBGp. Esto es, ofrece características de depuración remota para Eclipse PDT, NetBeans, Notepad++, Protoeditor, Komodo... ¡e incluso vim!!
- Xdebug incluye un cliente de depuración standalone y opensource: Xdebugclient 0.9.0
Instalación de Xdebug
Para instalar Xdebug (http://www.xdebug.org/) lo mejor es dejar que su propia Web nos indique qué fichero es el adecuado para nuestra configuración y cómo instalarlo.
Solo tenemos que pegar el fuente de un phpinfo() obtenido de nuestro sistema en http://www.xdebug.org/find-binary.php. En cuanto hagamos clic sobre el botón "Analyse my phpinfo() output" obtendremos las indicaciones.
En mi caso he obtenido lo siguiente:
Server API: Apache 2.0 Handler
Windows: yes - Compiler: MS VC6 - Architecture: x86
Zend Server: no
PHP Version: 5.3.4
Zend API nr: 220090626
PHP API nr: 20090626
Debug Build: no
Thread Safe Build: yes
Configuration File Path: C:\WINDOWS
Configuration File: C:\PHP\php.ini
Extensions directory: C:\PHP\ext
Solo tenemos que pegar el fuente de un phpinfo() obtenido de nuestro sistema en http://www.xdebug.org/find-binary.php. En cuanto hagamos clic sobre el botón "Analyse my phpinfo() output" obtendremos las indicaciones.
En mi caso he obtenido lo siguiente:
Summary
Xdebug installed: noServer API: Apache 2.0 Handler
Windows: yes - Compiler: MS VC6 - Architecture: x86
Zend Server: no
PHP Version: 5.3.4
Zend API nr: 220090626
PHP API nr: 20090626
Debug Build: no
Thread Safe Build: yes
Configuration File Path: C:\WINDOWS
Configuration File: C:\PHP\php.ini
Extensions directory: C:\PHP\ext
Instructions
- Download php_xdebug-2.1.0-5.3-vc6.dll
- Move the downloaded file to C:\PHP\ext
- Edit
C:\PHP\php.iniand add the line
zend_extension = C:\PHP\ext\php_xdebug-2.1.0-5.3-vc6.dll - Restart the webserver
lunes, 14 de marzo de 2011
Dónde y cómo crear el fichero .gitignore
En el apartado "Ignorando Archivos" de http://progit.org/book/es/ch2-2.html se explica de maravilla cómo evitar que vayan a parar a nuestro repositorio determinados ficheros (por ejemplo módulos compilados, ficheros de backup, ejecutables, etc.).
Solo he tropezado con un par de detalles, el dónde y el cómo. Pues bien, el fichero ".gitignore" hay que crearlo en el "working directory" del proyecto y no en el directorio ".git". Respecto al cómo, apuntar que los usuarios de Windows pueden tener problemas al tratar de guardar un fichero solo con extensión y sin nombre, pero se puede hacer fácilmente desde la consola de Git con el comando "git vi .gitignore" (sobre el manejo del editor vi hay información básica en http://es.wikipedia.org/wiki/Vi).
Es fácil ver si el .gitignore está surtiendo efecto. Si creamos o metemos un fichero de los que deseamos ignorar en el directorio de trabajo y hacemos un "git status", éste no aparecerá en la lista de los "Untrucked".
Solo he tropezado con un par de detalles, el dónde y el cómo. Pues bien, el fichero ".gitignore" hay que crearlo en el "working directory" del proyecto y no en el directorio ".git". Respecto al cómo, apuntar que los usuarios de Windows pueden tener problemas al tratar de guardar un fichero solo con extensión y sin nombre, pero se puede hacer fácilmente desde la consola de Git con el comando "git vi .gitignore" (sobre el manejo del editor vi hay información básica en http://es.wikipedia.org/wiki/Vi).
Es fácil ver si el .gitignore está surtiendo efecto. Si creamos o metemos un fichero de los que deseamos ignorar en el directorio de trabajo y hacemos un "git status", éste no aparecerá en la lista de los "Untrucked".
sábado, 12 de marzo de 2011
Clases y objetos en PHP 5
En el modelo de objetos de PHP 5 ha habido cambios muy importantes respecto a PHP 4 y es fundamental conocerlo a fondo. ¡En Symfony absolutamente todo son objetos!
Aquí hay una completa guía en español:
Aquí hay una completa guía en español:
Ajustando php.ini para Symfony2
He tenido que hacer algunos ajustes en el archivo php.ini por requerimiento de Symfony2. Se trata del valor de "date.timezone" de la sección [Date]. Yo le he asignado de la siguiente forma y me ha funcionado correctamente:
date.timezone= Europe/Madrid
TortoiseGit
Aunque Git dispone de un interfaz gráfico que se puede lanzar desde la consola mediante el comando "gitk", TortoiseGit nos ofrece muchas más posibilidades directamente desde el explorador de archivos de Windows. En primer lugar, con sus indicadores visuales podemos ver el estado de los ficheros y carpetas de nuestro proyecto:
Y con clic derecho disponemos de un amplio menú contextual para interactuar con Git.
Respecto a la instalación no hay mucho que decir. Es muy sencilla y no requiere ajustes posteriores, al menos por lo que he podido ver hasta ahora.
Y con clic derecho disponemos de un amplio menú contextual para interactuar con Git.
Respecto a la instalación no hay mucho que decir. Es muy sencilla y no requiere ajustes posteriores, al menos por lo que he podido ver hasta ahora.
Cambiar el directorio de datos de MySQL
Por defecto, el directorio en el que MySQL guarda las bases de datos es del estilo del siguiente:
C:\Documents and Settings\All Users\Datos de programa\MySQL\MySQL Server 5.5\data
Para cambiarlo, hay que editar el archivo my.ini del directorio donde se instala MySQL y modificar el valor de datadir poniendo la ruta al nuevo directorio de datos. Yo, por ejemplo, he puesto lo siguiente
Una vez hecho esto he movido el contenido de la antigua carpeta de datos a la nueva y he reiniciado el servicio MySQL.
C:\Documents and Settings\All Users\Datos de programa\MySQL\MySQL Server 5.5\data
Para cambiarlo, hay que editar el archivo my.ini del directorio donde se instala MySQL y modificar el valor de datadir poniendo la ruta al nuevo directorio de datos. Yo, por ejemplo, he puesto lo siguiente
datadir="C:/MyData/MySQLData/"
Una vez hecho esto he movido el contenido de la antigua carpeta de datos a la nueva y he reiniciado el servicio MySQL.
jueves, 10 de marzo de 2011
Instalación de PHP
Según lo que se indica en esta página, Symfony2 necesita como mínimo una versión 5.3 de PHP.
Tras instalar Apache (tal y como comento en la entrada anterior) he ido a la página de descargas de PHP para Windows y he descargado e instalado php-5.3.4-Win32-VC6-x86.msi. Éste configura automáticamente el servidor Web y por tanto resulta muy muy fácil de instalar.
IMPORTANTE:
Como hay muchas versiones a elegir, conviene visitar esta página http://windows.php.net/download/ y leer las indicaciones del apartado "Which version do I choose?" de la parte izquierda. De entrada nos dice que para Apache hay que utilizar los VC6 (no los VC9) y yo he descartado los que contienen "nts" en el nombre, ya que éstos no configuran automáticamente con Apache y además no tienen los ficheros php5apache2_2.dll necesarios para que PHP pueda trabajar como un módulo de Apache.
Por tanto si tras instalar PHP, éste no te funciona y no puedes configurar manualmente el httpd.conf de Apache porque te faltan ficheros del tipo php5apache2_2.dll, no has elegido la versión correcta del instalador de PHP.
Tras instalar Apache (tal y como comento en la entrada anterior) he ido a la página de descargas de PHP para Windows y he descargado e instalado php-5.3.4-Win32-VC6-x86.msi. Éste configura automáticamente el servidor Web y por tanto resulta muy muy fácil de instalar.
IMPORTANTE:
Como hay muchas versiones a elegir, conviene visitar esta página http://windows.php.net/download/ y leer las indicaciones del apartado "Which version do I choose?" de la parte izquierda. De entrada nos dice que para Apache hay que utilizar los VC6 (no los VC9) y yo he descartado los que contienen "nts" en el nombre, ya que éstos no configuran automáticamente con Apache y además no tienen los ficheros php5apache2_2.dll necesarios para que PHP pueda trabajar como un módulo de Apache.
Por tanto si tras instalar PHP, éste no te funciona y no puedes configurar manualmente el httpd.conf de Apache porque te faltan ficheros del tipo php5apache2_2.dll, no has elegido la versión correcta del instalador de PHP.
Instalación de Apache HTTP Server
He instalado sin ningún problema la versión 2.2.17 disponible en esta página: http://httpd.apache.org/download.cgi.
He elegido httpd-2.2.17-win32-x86-no_ssl.msi, es decir la versión "Win32 Binary without crypto (no mod_ssl) (MSI Installer)". De momento lo he hecho sin saber con certeza cuál es la versión adecuada (si es que hay alguna preferible) para Symfony2.
Solo destacar que, una vez instalado, he cambiado la carpeta raíz del servidor Web . He modificado el fichero httpd.conf de la carpeta "conf" donde se instaló Apache modificando este valor:
DocumentRoot "C:/MyData/Source/WebServer"
Esto, lógicamente no es imprescindible. Yo lo he hecho para ajustarlo a mi particular organización del disco duro. Luego, como siempre que modificamos httpd.conf, hay que reiniciar Apache para que los cambios surtan efecto.
He elegido httpd-2.2.17-win32-x86-no_ssl.msi, es decir la versión "Win32 Binary without crypto (no mod_ssl) (MSI Installer)". De momento lo he hecho sin saber con certeza cuál es la versión adecuada (si es que hay alguna preferible) para Symfony2.
Solo destacar que, una vez instalado, he cambiado la carpeta raíz del servidor Web . He modificado el fichero httpd.conf de la carpeta "conf" donde se instaló Apache modificando este valor:
DocumentRoot "C:/MyData/Source/WebServer"
Esto, lógicamente no es imprescindible. Yo lo he hecho para ajustarlo a mi particular organización del disco duro. Luego, como siempre que modificamos httpd.conf, hay que reiniciar Apache para que los cambios surtan efecto.
Instalación de herramientas para trabajar con Symfony2
Como ya voy a empezar a hacer pruebas reales con Symfony2 (ya que ya el capítulo 2 de "The Book" lo requiere) voy a necesitar de una serie herramientas. Las voy a instalar desde cero para así disponer de una instalación "en limpio" de todas ellas. Lo voy a hacer sobre Windows y van a ser las siguientes:
Como existe amplia información en Internet sobre el proceso de instalación de todas ellas, solo escribiré alguna nota cuando me encuentre alguna dificultad o haya algún detalle que aclarar que pueda ser útil o ahorre trabajo.
Yo prefiero la instalación individual pero, para los que prefieran hacerlo todo de golpe, existe WampServer que instalada simultáneamente muchas de estas herramientas.
- Git (ya comentamos la instalación en esta entrada)
- TortoiseGit
- Apache HTTP Server
- PHP
- Xdebug
- MySQL
- NetBeans IDE
Como existe amplia información en Internet sobre el proceso de instalación de todas ellas, solo escribiré alguna nota cuando me encuentre alguna dificultad o haya algún detalle que aclarar que pueda ser útil o ahorre trabajo.
Yo prefiero la instalación individual pero, para los que prefieran hacerlo todo de golpe, existe WampServer que instalada simultáneamente muchas de estas herramientas.
Empezando con Symfony2
Después de haber dedicado varias entradas a Git para fijar al menos algunas nociones sobre él, vuelvo a Symfony2. Más que volver, empiezo, y el punto de partida es el "Quick Tour" accesible desde
Es bastante breve y va al grano. Al menos en un primer vistazo, aunque va aclarando algunos conceptos no me resulta fácil entender el fondo.
Después se nos remite "The Book" un manual más amplio sobre Symfony2 disponible en
Antes de descubrir el "Quick Tour" me había leído con detenimiento el primer capítulo "Introducción a Symfony 2 y HTTP" y creo que es un magnífico comienzo partiendo de los orígenes y recuperando la perspectiva de lo que es una petición y una respuesta vía HTTP. Por lo pronto nada que añadir, solo decir que hay muchas ganas de abordar el capítulo siguiente.
Es bastante breve y va al grano. Al menos en un primer vistazo, aunque va aclarando algunos conceptos no me resulta fácil entender el fondo.
Después se nos remite "The Book" un manual más amplio sobre Symfony2 disponible en
Antes de descubrir el "Quick Tour" me había leído con detenimiento el primer capítulo "Introducción a Symfony 2 y HTTP" y creo que es un magnífico comienzo partiendo de los orígenes y recuperando la perspectiva de lo que es una petición y una respuesta vía HTTP. Por lo pronto nada que añadir, solo decir que hay muchas ganas de abordar el capítulo siguiente.
miércoles, 9 de marzo de 2011
El mejor manual de Git
Mi búsqueda de información sobre Git y algunas pruebas con el producto me han permitido escribir varias entradas sobre mis primeras experiencias con este sistema de control de versiones. También he elaborado una pequeña lista de enlaces interesantes (se encuentran en el apartado "Enlaces" del blog), pero creo que he encontrado el manual ideal. Para todo aquel que quiera un manual es español, útil, riguroso y perfectamente estructurado les recomiendo esta página: Pro Git en español.
domingo, 6 de marzo de 2011
Git - Aclarando conceptos: working directory, staging area y repositorio
Comprender la lógica de trabajo de Git requiere entender con claridad estos tres conceptos. Para ello recomiendo la lectura de esta página del fantástico libro "Pro Git" (http://progit.org/book/es/) y, en particular, del apartado "Los tres estados". De él he extraído de forma casi literal estas tres definiciones:
Los archivos nuevos y los modificados se "pasan" primero al área de preparación (staging area) para luego pasarlos definitivamente al repositorio. Por tanto, los ficheros temporales, ejecutables, etc. que no queremos que vayan al repositorio bastará con que no los pasemos nunca al área de preparación (mediante "git add"). Al no hacerlo, Git los ignorará totalmente.
De esta forma podemos controlar perfectamente los archivos que gestionará Git de nuestro directorio de trabajo y que formarán parte del repositorio. En general no tiene sentido, por ejemplo, que estemos guardando en el repositorio cada cambio de un ejecutable que en todo momento podemos generar con el código fuente que por supuesto sí guardamos en él.
- El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para el proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador. Es el que contiene el repositorio (repository).
- El directorio de trabajo (working directory) es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar. Se puede decir que es el que aloja físicamente los archivos del proyecto.
- El área de preparación (staging area) es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación. A veces se denomina el índice (index), pero se está convirtiendo en estándar el referirse a ello como el área de preparación.
Los archivos nuevos y los modificados se "pasan" primero al área de preparación (staging area) para luego pasarlos definitivamente al repositorio. Por tanto, los ficheros temporales, ejecutables, etc. que no queremos que vayan al repositorio bastará con que no los pasemos nunca al área de preparación (mediante "git add"). Al no hacerlo, Git los ignorará totalmente.
De esta forma podemos controlar perfectamente los archivos que gestionará Git de nuestro directorio de trabajo y que formarán parte del repositorio. En general no tiene sentido, por ejemplo, que estemos guardando en el repositorio cada cambio de un ejecutable que en todo momento podemos generar con el código fuente que por supuesto sí guardamos en él.
sábado, 5 de marzo de 2011
Git para Dummies - Paso 3 - Empezando por fin
Vamos, por fin, a tratar de dar los primeros pasos trabajando realmente con Git. Para ello voy a recurrir a un proyecto ficticio sobre el que haré las pruebas. He creado en mi disco duro una carpeta llamada "MiProyecto" y dentro he creado dos simples ficheros de texto llamados "ModuloA.txt" y "ModuloB.txt" (he evitado las tildes deliberadamente) cuyo contenido es "Fuente A - Versión 1" y "Fuente B - Versión 1" respectivamente.
Ahora vamos a lanzar el Git Bash en el directorio del proyecto. Bastará con un clic con el botón derecho sobre la carpeta y elegir la opción "Git Bash". Ya tenemos la consola de Git en pantalla. Empezamos!
Ahora vamos a lanzar el Git Bash en el directorio del proyecto. Bastará con un clic con el botón derecho sobre la carpeta y elegir la opción "Git Bash". Ya tenemos la consola de Git en pantalla. Empezamos!
- Paso 1: Creamos un repositorio local con el comando "git init". Esto creo un repositorio local vacío en una carpeta oculta llamada ".git" con una estructura como la que se muestra a continuación:
- Paso 2: Ejecutamos "git add ." para añadir todos los ficheros del proyecto al llamado "index" o "staging area".
- Paso 3: Ejecutamos 'git commit -m "Primera copia"' para grabar los cambios de los ficheros registrados en el "staging area" en el repositorio.
Esto es solo un pequeño "aperitivo", un ejemplo de uso de la consola de Git para, al menos, dar un idea de cómo se trabaja con él. En otras entradas iremos profundizando en conceptos, comandos, etc. que creo aclararán al que no lo sepa o haya entendido qué hemos hecho exactamente con estas tres instrucciones.
Aprovecho para recordar que desde la consola podemos obtener directamente ayuda sobre un comando determinado mediante "git help <comando>", por ejemplo "git help commit". Y si simplemente ejecutamos "git" se mostrará la lista de comandos disponibles.
Aprovecho para recordar que desde la consola podemos obtener directamente ayuda sobre un comando determinado mediante "git help <comando>", por ejemplo "git help commit". Y si simplemente ejecutamos "git" se mostrará la lista de comandos disponibles.
Git para Dummies - Paso 2 - Git Bash - Nociones
Como se vio en la entrada anterior, tras la instalación de Git, una de las nuevas opciones de que disponemos en el menú de programas de Windows es "Git"->"Git Bash". He extraído esta definición de "Bash" de la Wikipedia:
Por tanto, el nombre (Git Bash) ya nos dice mucho. Se trata de una consola desde la que ejecutar comandos de Git. El aspecto es como el de la imagen siguiente:
En esta ventana se pueden ejecutar los comandos Linux más habituales, por ejemplo ls, cd, pwd, etc. (clic aquí para una lista completa) pero la idea es ejecutar comandos de Git, como podría ser por ejemplo "git commit". Para conocer los comandos de Git basta con ejecutar "git".
Si en el proceso de instalación hemos elegido "Run Git from de Windows Command Prompt" también podemos ejecutar comandos de Git directamente desde el símbolo del sistema de Windows . En el pantallazo que sigue se ha llamado a Git desde el símbolo del sistema:
Bash es un programa informático cuya función consiste en interpretar órdenes. Está basado en la shell de Unix y es compatible con POSIX. Fue escrito para el proyecto GNU y es el intérprete de comandos por defecto en la mayoría de las distribuciones de Linux.
(Para información mucho más detallada: http://es.wikipedia.org/wiki/Bash)
Por tanto, el nombre (Git Bash) ya nos dice mucho. Se trata de una consola desde la que ejecutar comandos de Git. El aspecto es como el de la imagen siguiente:
En esta ventana se pueden ejecutar los comandos Linux más habituales, por ejemplo ls, cd, pwd, etc. (clic aquí para una lista completa) pero la idea es ejecutar comandos de Git, como podría ser por ejemplo "git commit". Para conocer los comandos de Git basta con ejecutar "git".
Si en el proceso de instalación hemos elegido "Run Git from de Windows Command Prompt" también podemos ejecutar comandos de Git directamente desde el símbolo del sistema de Windows . En el pantallazo que sigue se ha llamado a Git desde el símbolo del sistema:
En esta ventana lógicamente lo que el sistema entiende son los comandos habituales de Windows y no los de Linux como en el caso del Git Bash pero, igualmente, para ejecutar comandos de git basta con escribirlos en la forma "git comando".
MUY IMPORTANTE: Desde la consola podemos obtener directamente ayuda sobre un comando determinado mediante "git help <comando>", por ejemplo "git help commit". Y si simplemente ejecutamos "git" se mostrará la lista de comandos disponibles.
Git para Dummies - Paso 1 - Instalación en Windows
Como el primer "dummie" total en sistemas de control de versiones, y por supuesto en Git, es el que escribe, hay que tomar estas entradas como un mero reflejo de mi experiencia desde la absoluta y total inexperiencia y desconocimiento de Git. Con el tiempo iré corrigiendo los errores que pueda en estos textos, pero espero que puedan servir al menos para ayudar a otros en algún aspecto.
Bueno, al grano. De momento sigo estos pasos:
Una vez terminada la instalación, lo primero que encuentro es una nueva opción llamada "Git" en el menú de programas de Windows. Ésta me da acceso a otras dos: "Git Bash" y "Git GUI" como se muestra en la imagen que sigue:
Ahora, aunque ya se intuye, habrá que averiguar qué es exactamente cada cosa.
El otro cambio que se puede percibir tras la instalación es que en los menús contextuales (al hacer clic con el botón derecho) de cualquier carpeta aparecen estas tres nuevas opciones:
Vamos a ver qué es todo esto para tratar de entender lo mejor posible cómo funciona Git, pero mi idea (no sé todavía si errónea) es recurrir más adelante a TortoiseGit que parece ofrecer una forma más intuitiva y sencilla de utilizarlo.
Por lo pronto aclarar que llamar al Git Gui (Graphic User Interface for Git) desde el menú de Windows (Imagen A) o desde el contextual de una carpeta (Imagen B) resulta totalmente indiferente. Se abre la aplicación exactamente de la misma forma. A continuación se muestra un pantallazo:
En el caso de Git Bash la cosa cambia. Si lo ejecutamos desde el menú contextual de una carpeta (Imagen B) la consola estará ya ubicada en ese directorio y si lo ejecutamos desde el menú de programas de Windows (Imagen A) se abrirá en el directorio actual del sistema, por ejemplo "C:\Documents and Settings\PCXX".
Bueno, al grano. De momento sigo estos pasos:
- Me dirijo a la Web oficial de Git: http://git-scm.com/
- Hago clic en el enlace "Dowload" y luego en el enlace "Windows" del apartado "Download Git"
- Descargo "Git-1.7.4-preview20110204.exe"
Al ejecutar el instalador tomo las opciones por defecto que el programa propone excepto en el primer paso. En éste elijo "Run Git from the Windows Command Prompt" porque creo que me facilitará las cosas. A continuación muestro en imágenes las tres elecciones que he hecho:
Una vez terminada la instalación, lo primero que encuentro es una nueva opción llamada "Git" en el menú de programas de Windows. Ésta me da acceso a otras dos: "Git Bash" y "Git GUI" como se muestra en la imagen que sigue:
Imagen A
Ahora, aunque ya se intuye, habrá que averiguar qué es exactamente cada cosa.
El otro cambio que se puede percibir tras la instalación es que en los menús contextuales (al hacer clic con el botón derecho) de cualquier carpeta aparecen estas tres nuevas opciones:
Imagen B 
Vamos a ver qué es todo esto para tratar de entender lo mejor posible cómo funciona Git, pero mi idea (no sé todavía si errónea) es recurrir más adelante a TortoiseGit que parece ofrecer una forma más intuitiva y sencilla de utilizarlo.
Por lo pronto aclarar que llamar al Git Gui (Graphic User Interface for Git) desde el menú de Windows (Imagen A) o desde el contextual de una carpeta (Imagen B) resulta totalmente indiferente. Se abre la aplicación exactamente de la misma forma. A continuación se muestra un pantallazo:
En el caso de Git Bash la cosa cambia. Si lo ejecutamos desde el menú contextual de una carpeta (Imagen B) la consola estará ya ubicada en ese directorio y si lo ejecutamos desde el menú de programas de Windows (Imagen A) se abrirá en el directorio actual del sistema, por ejemplo "C:\Documents and Settings\PCXX".
miércoles, 2 de marzo de 2011
¿Git o SubVersion (SVN)?
En cuanto a software de control de versiones para Symfony, el dilema está absolutamente claro: hay que utilizar Git. ¿Por qué? Pues porque Git es el oficial para Symfony 2. Así que Subversion descartado.
Sin duda se han decantado por Git porque éste presenta muchas ventajas. Es opensource, distribuido, no intrusivo, está disponible para Windows, Linux y Mac, etc. Y tiene una característica desde mi punto de vista especialmente destacable: ¡permite llevar un control de versiones incluso de ficheros binarios!
Dos enlaces para ir echando un vistazo:
Sin duda se han decantado por Git porque éste presenta muchas ventajas. Es opensource, distribuido, no intrusivo, está disponible para Windows, Linux y Mac, etc. Y tiene una característica desde mi punto de vista especialmente destacable: ¡permite llevar un control de versiones incluso de ficheros binarios!
Dos enlaces para ir echando un vistazo:
Si se desconoce totalmente Git o los sistemas de control de versiones aquí hay unos vídeos estupendos y en español. Aunque modestos en la realización, creo que pueden resultar muy útiles para descubrir qué es Git y cómo empezar a utilizarlo. De hecho, en parte, me he inspirado en alguno de ellos para escribir algunas de las próximas entradas.
- Introducción a Git 1/5
Se explica qué es Git y cuales son sus prestaciones, características fundamentales y ventajas frente a otros sistemas de control de versiones. - Introducción a Git 2/5
- Introducción a Git 3/5
- Introducción a Git 4/5
- Introducción a Git 5/5
Suscribirse a:
Entradas (Atom)