Charla git

Git en el mundo real
Angel Roldán @senechaux · David Pordomingo @rizomeEs C/Campomanes 6, 5ºizq; 28013 Madrid Spain

Ángel Roldán David Pordomingo
@senechaux @rizomeEs
¿ Quiénes sómos ?
y venimos de...

¿Qué hacemos en Acilia?

¿ y qué os vamos a contar?
Nuestra evolución
Cómo hacemos que se cumplan las normas
Cómo nos complicamos la vida, y cómo nos la solucionamos

Evolución. Prehistoria (3 años, 3 personas)
Entorno de validación similar al de producción
Ramas: todo el trabajo se realiza sobre <master>

Evolución. El equipo crece (2’5 años, 4 personas)
Entorno de validación con rama fija: preprod
Entorno de pruebas independiente con rama variable
Ramas: sólo si se prevé un desarrollo largo
- para todo lo demás: <master>

Evolución. La cantidad de issues crece (1 año, 6-8 personas)
Ramas: se recomienda una por cada issue
Commits: sin reglas; pueden desarrollarse fixes o tareas pequeñas sobre master.
- nombres: sin política (wip, wip2, definitivo, ahorasi)

Evolución. Commits everywhere… (6 meses, 8 personas)
Ramas: una para cada issue
- nombres: prefijo ISSUE-XXX
Commits: siempre en rama dedicada a la tarea
- nombres: sin política

Evolución. Control del desarrollador (2 meses, 8-10 personas)
- nombres: prefijo ISSUE-XXX
- nombres: sin política
Fork por cada persona
Pull-request a través de GitHub
- aprobación automática por el desarrollador

Evolución. Poniendo el foco en la calidad (1 mes, 8-10 personas)
- nombres: prefijos ISSUE-XXX, FEATURE/, CLEANUP/, COSMETICS/, FIX/, HOTFIX/, HOTFIX/ISSUE-XXX
- nombres: precedido por el nombre de la rama
- code-review dependiente de la criticidad

Evolución. Poniendoselo fácil al desarrollador (10 personas)
Múltiples entornos de validación, uno por cada rama a validar
Cumplimiento de estándares asegurado mediante hooks
- lanzados desde la consola
- ¿gitflow?

Evolución. Estadios pasados.
3 👥
3 años
4 👥
2,5 años
6-8 👥
1 año
8 👥
6 meses
8-10 👥
2 meses
8-10 👥
1 mes
entornos prod
pre
prod
pre
prod = pre
staging
prod = pre
staging
prod = pre
staging
prod = pre
staging
ramas master sólo para
desarrollos
recomend.
por issue
obligatorio
por issue
obligatorio
por issue
obligatorio
por issue
commits rama propia rama propia rama propia
naming ISSUE-XXX ISSUE-XXX prefijos
forks personales personales
PR auto
aprobados
code review

la cosa avanza, vamos por el ecuador
Nuestra evolución

Cumpliendo normas. ¿Qué normas?
Compromiso con la calidad.
Compromiso con la agilidad.
Elección de estándard.
Haciendo que se cumplan las normas
Recomendación: rebase antes de PR y squashing
Git-Hooks

Cumpliendo normas. Nombres de commits bonicos
<prepare-commit-msg> Tomando el nombre de la rama
<commit-msg> Validando que el mensaje del commit sigue las normas

Cumpliendo normas. Code standards
<pre-commit> Asegurando que el código cumple con nuestros estándares

Cumpliendo normas. Cada commit en su sitio
<pre-commit> Asegurando que no se sale ningún commit de su issue
<pre-push> Asegurando que nadie intenta pushear sobre ramas públicas

cinco minutos y estos dos se retiran
Nuestra evolución

CMS, git y BDD. Editores vs desarrolladores
Desincronización entre los templates de la BDD -que manipulan
los editores-, y los mismos templates que editamos desde
nuestro IDE.

CMS, git y BDD. Mandando mails desde el CMS
Primer acercamiento: mandar un email cuando se edita un
template desde el CMS

CMS, git y BDD. Commiteando desde el CMS
Segundo acercamiento: comiteando desde el CMS

CMS, git y BDD. Pull-request desde el CMS ¿orly?
Segunda vuelta: actualizando la BDD con los datos del
repositorio.

bibliografía
http://git-scm.com/book/en/v2
(para rellenar: en castellano) http://librosweb.es/libro/pro_git
https://github.com/brigade/overcommit
y evidentemente:
http://stackoverflow.com/questions/tagged/git

bibliografía

Charla git

Recomendados

Recomendados

Más contenido relacionado

Similar a Charla git

Similar a Charla git (20)

Último

Último (7)

Charla git