Limitantes de TFS

Limitantes de TFS

El servidor está en un equipo de la intranet, si se apaga ese equipo nos quedamos sin poder subir cambios

Crear una rama para poder trabajar en un feature nuevo es costoso por lo que se comparte siempre la base de código

Si estamos trabajando en un cambio y queremos postergarlo para después, la función shelve necesita la misma revisión base de los archivos modificados

Limitantes de TFS

Para buscar la historia de un archivo debemos tener conexión al servidor

Para modificar un archivo, es necesario hacer checkout (automático, pero requiere conexión al servidor) o se trabaja offline y después requiere sincronización

¿Otros problemas?

¿Por qué usar git?

¿Por qué usar git?

Los commits de cada uno son locales hasta que se publican a los repositorios remotos (ej: Assembla)

Sistema de versionado distribuido: todos tienen la historia entera y las ramas (opcional)

No es necesario tener conexión remota para modificar archivos ni para generar un commit en nuestro repositorio

Si realizamos un commit equivocado podemos corregirlo (ammend) o deshacerlo por completo

¿Por qué usar git?

Si estamos trabajando en un cambio que no queremos publicar, podemos crear un stash (equivalente a shelve)

Crear una rama nueva es equivalente a crear un puntero, no requiere conexión al servidor

O también podemos crear un branch y hacer el commit sobre ese branch sin tener que copiar a mano los cambios

Cambiarse de una rama a otra se hace en el mismo directorio, no requiere mapear toda la nueva rama

¿Por qué usar git?

Un commit es un checkpoint de nuestro trabajo, pero no tiene porqué estar completo. Posteriormente podemos editar la historia de commits antes de publicarlos

Cómo cada copia es un repositorio en sí, todas las operaciones que antes necesitabamos un servidor, podemos realizarlas localmente

Podemos crear ramas que sean para uso personal y no publicarlas al resto del equipo

Podemos hacer varios commits y luego mergearlos como un solo commit (squash)

¿Por qué usar git?

Cada desarrollador va generando commits en esa rama con los hitos que entienda importantes

Una forma de trabajo, llamada git flow, consiste en hacer un branch por cada feature que se trabaja

Cuando entiende que la historia está pronta, realiza un merge request hacia la rama principal

Otro se encarga de revisarlo (code review) y sugerir posibles mejoras

Finalmente, el desarrollador realiza el merge hacia la rama principal de desarrollo

¿Qué diferencias hay?

¿Qué diferencias hay?

Para que otros puedan disponer nuestros cambios, es necesario publicar (push) a un repositorio remoto

Al ser un repositorio distribuido, los commits realizados quedan son locales hasta que se publican

Para obtener los últimos cambios, realizamos un pull que consta de obtener lo último del repositorio remoto (fetch) y hacer el merge hacia nuestra copia de trabajo

¿Qué diferencias hay?

En git se identifican 3 etapas de versionado: working, staged, commited

Todos aquellos cambios que se están realizando en nuestro repositorio, están en la etapa working

Antes de poder hacer commit, es necesario agregar los cambios al índice (staging), estos son los que se seleccionan para el commit

Finalmente, al realizar commit, todos los cambios que están en stage se guardan en el repositorio

¿Qué diferencias hay?

La forma más eficaz de realizar los cambios en git es con la línea de comandos

git add ...archivos (para agregar al índice)

git commit -m "mensaje" (para guardar cambios)

git pull (para obtener los cambios remotos y mergearlos)

git push (para publicar los cambios al repositorio remoto)

También disponemos de una integración en Visual Studio o podemos usar SourceTree

Forma de trabajo propuesta

Forma de trabajo propuesta

Cada uno hace commit de sus cambios y debe publicarlos a assembla para que el build de TeamCity lo tome

Inicialmente, continuar trabajando en git tal cómo lo hacemos en tfs mientras nos adaptamos a la herramienta

Todos trabajan sobre la rama master (dev) y se hace una rama para cada release

La historia de tfs se sigue migrando hacia git, así que podemos terminar lo que estemos haciendo

Forma de trabajo propuesta

Usar la rama master como producción, etiquetando los releases, y trabajar sobre otra rama (dev) desde dónde se hacen los builds de QA

Una vez que estemos familiarizados con git, podemos cambiar la metodología de trabajo con el cvs

Cada feature se puede hacer en un branch separado, compartido entre quienes estén trabajandolo y luego integrarlo a la rama de desarrollo cuando esté pronta

Sitios de interés

Sitios de interés

Tutorial de git flow:

https://atlassian.com/git/tutorials/comparing-workflows/

Guía de git, conceptos que explican como funciona:

https://jwiegley.github.io/git-from-the-bottom-up/

SourceTree GUI para git:

https://www.sourcetreeapp.com/

Las mejoras prácticas de git:

https://www.originate.com/library/git-guide

Washu-sitios de interés

http://gggritso.com/human-git-aliases

http://41j.com/blog/2015/02/common-git-screwupsquestions-solutions/

http://drewfradette.ca/a-simpler-successful-git-branching-model/

https://git-scm.com/blog/2011/07/11/reset.html

https://git-scm.com/book/en/v1/Git-Basics-Tips-and-Tricks

http://learngitbranching.js.org/