lunes, 18 de abril de 2016

Control de versiones de tu proyecto con GIT + Bitbucket

Registrar un nuevo repositorio. Desde la pantalla principal de Bitbucket, navegá a Repositorios > Crear un nuveo repositorio. Ingresá un nombre y dale click a “Crear”.
mkdir ./DemoRepo
cd ./DemoRepo

Crear el directorio del proyecto en tu computadora. Abrí una terminal, dirigite a la ubicación donde te gustaría tener el repo, e ingresá:

Iniciar el repo en tu máquina local.
git init
git remote add origin https://tuUsername@bitbucket.org/tuUsername/demorepo.git

Incluí los archivos de tu proyecto en este directorio. Si ya iniciaste un proyecto, simplemente copiá y pegá los archivos a esta ubicación.

Comprobá el estado de tu repo. Desde la terminal:
git status

Ahi vas a ver listado todos los archivos que han sido modificados desde el último snapshot (o commit). Como este es el primero, vas a ver listado todos los archivos.

Aceptá los cambios y creá un commit:
git commit -am "This is the first commit. Please write something descriptive here!"

Si este snapshot es realmente importante y querés resaltarlo de otros existentes, podés usar tags. Estos tags se aplican al último commit en tu repositorio local. Para ello:
git tag -a v1.0 -m "Initial working version"
Y es muy importante que para que otros puedan ver estos tags cuando los subas al repo general, lo hagas mediante:
git push --follow-tags

Si te olvidás de ese parámetro, solamente vos vas a ver el tag en tu repo local. Este último comando, push, subió tu snapshot al repositorio general... o al menos lo intentó. ¿Por qué digo esto? Porque si mientras vos hacías estos cambios a la versión inicial, alguien más hizo otro cambio, subió al repositorio general, y las líneas que modificaron son las mismas, git no va a dejarte subir tu commit tan fácilmente. Vas a tener que hacer un merge. Pero eso lo vemos más adelante, porque probablemente aquí tengas que configurar algo más:

Configurar la acción por default de “push” sobre el repo remoto. Acá tenés dos opciones: matching o simple. La primera hará que cuando hagas push, todas las ramas (branches) que tenés en el repositorio se actualicen. La segunda, que solo se actualice la rama sobre la cual estás trabajando. Yo prefiero la segunda, sobre todo si laburás en equipo.
git config --global push.default simple

Si aún no podés hacer push, puede que aún debas configurar la rama maestra. Para ello basta con agregar los siguientes parámetros:
git push --follow-tags --set-upstream origin master


Tranca. Esto solo vas a necesitarlo la primera vez. Y si no tenés nuevos tags que actualizar, te va a bastar con un simple “git push” de ahora en más.

Especifića que archivos no deberían incluirseen el commit. Esto puede ser útil para excluir archivos temporales o clases compiladas. Para ello, en la raiz del repositorio, desde la terminar ejecutá:
git rm --cached `git ls-files -i --exclude-from=.gitignore`
gedit .gitignore


Agregá la ruta a las carpetas y/o archivos que quieras excluir. Ojo, esto hace que no se suban al repo, no solo que no se "trackeen". Podés reemplazar "gedit" por tu editor de texto de preferencia.

Visualizá tus commits. 
Ahora solo tenés que laburar en tu proyecto y hacer commits y pushs cada vez que lo creas necesario. ¿Es bueno hacer commit cada vez que dejo de laburar en algo? Mmm… No. Nada te lo impide, pero es bueno hacer commits solo de versiones que tengan alguna nueva funcionalidad en buen estado, no a medias. Esto es tanto más importante para con los push. (no queremos joder a otros con constantes cambios). Pero en definitiva, es algo que seguramente vas a acordar con tus compañeros de equipo.

¿Que puedo necesitar de ahora en más?

  • Mergear commits
  • Hacer stasing, en lugar de commit
  • Volver atrás para comparar alguna versión vieja de un archivo o proyecto
  • Volver a laburar con una versión vieja de un archivo/proyecto (revertir commits)
  • Laburar con branches