Git Workflow Colaboración · Michel + Noelia

TL;DR · 3 reglas para no pisarse

1. Trabajás siempre en branch dedicado tuyo noelia-XYZ. Día 1 Michel crea con vos el primer branch noelia-etsy-launch. Después cada task largo (Wedding template, brand identity, etc) tiene su branch propio. Michel resta en main.
2. Siempre git pull antes de git push en tu branch. Si saltás esto, Git te rechaza con error claro (no rompe nada, te avisa).
3. Merge a main via PR controlado (cuando task tuyo está completo). Michel reviewa + merge. Audit trail rigoroso, zero rischio overlap.

3 escenarios · que pasa cuando salvamos commits

Los tres casos posibles cuando vos + Michel trabajan en el mismo repo sharkcode. De seguro a riesgoso.

# Día 1 vos creas tu primer branch (Michel te guida)
git checkout main
git pull origin main
git checkout -b noelia-etsy-launch

# Trabajás durante el día
git add clients/noelia-etsy/listings/etsy-001.md
git commit -m "feat(noelia-etsy): primer listing draft ES + EN"

# Push a tu branch (NO main directo, NUNCA)
git push origin noelia-etsy-launch

# Michel queda en main, no se entera ni le importa
# Cuando tu task completo + revisado, merge a main via PR controlado

# Push final tu branch
git push origin noelia-etsy-launch

# Mensaje WhatsApp a Michel:
# "Listo branch noelia-etsy-launch para review + merge a main"

# Michel hace:
#   git checkout main
#   git pull origin main
#   git merge --no-ff noelia-etsy-launch
#   git push origin main
#   git branch -d noelia-etsy-launch  (delete local)
#   git push origin --delete noelia-etsy-launch  (delete remote, opcional)

# Después vos recreas branch fresh para próximo task
git checkout main
git pull origin main
git checkout -b noelia-cliente-X-launch

# Vos antes de empezar la sesion
git pull origin main          # Bajás los cambios de Michel del día anterior

# Trabajás durante el día
git add clients/noelia-etsy/listings/etsy-001.md
git commit -m "feat(noelia-etsy): listing 1 draft ES + EN"

# Antes de subir, pull otra vez (Michel pudo haber pushed mientras vos trabajabas)
git pull origin main          # Git mergea automatic porque archivos diferentes
git push origin main          # Sube limpio

# Vos haces git pull y Git dice:
CONFLICT (content): Merge conflict in .planning/stato-lavoro-os.md
Auto-merging .planning/stato-lavoro-os.md
Automatic merge failed; fix conflicts and then commit the result.

# El archivo tendrá marcadores que vos ves abriendo VSCode:
<<<<<<< HEAD
[tu version del párrafo]
=======
[la version de Michel]
>>>>>>> main

# Lo arreglás manualmente (decidís qué línea queda) + commit
git add .planning/stato-lavoro-os.md
git commit -m "merge: resolve stato-lavoro-os conflict"
git push

Ownership map · quién toca qué

Para evitar Escenario C confuso, sabemos antes quién es owner de qué directorio. Si querés tocar algo del lado Michel, avisás en chat.

Daily workflow · paso a paso

Tu rutina cada vez que abrís el laptop para trabajar. Memorizada en 3-5 días.

Mañana · empezar la sesion

# 1. Ir al repo
cdsc                           # alias zshrc, va a ~/Code/sharkcode

# 2. Bajar cambios de Michel (commit que pueda haber hecho la noche anterior)
gp                             # alias = git pull

# 3. Ver qué hay nuevo (opcional, para entender contexto)
gl                             # alias = git log --oneline -10

# 4. Abrir VSCode workspace multi-root
code ~/Code/noelia.code-workspace

Durante el día · trabajar

# Editás archivos via Claude o manual VSCode

# Ver qué cambió (cuando querés)
gs                             # alias = git status

# Cuando terminás un bloque de trabajo (cada 1-2 hr), commit
git add clients/noelia-etsy/listings/etsy-001.md
gc "feat(noelia-etsy): listing 1 draft ES translation"
# alias gc = git commit -m

Tarde/noche · cerrar la sesion

# 1. Pull primero (Michel pudo haber pushed durante el día)
gp                             # git pull

# 2. Si pull mergea automatic = OK, push
git push origin main

# 3. Si pull dice CONFLICT en algún archivo, ver Escenario C arriba
# (raro, generalmente solo si tocaste shared file sin avisar)

Si pasa conflict · paso a paso resolver

Primera vez que te pasa, abrir esta sección. Después memorizado en 5 min.

1. NO entres en panic. Conflict no rompe nada, solo Git te pide ayuda para decidir qué línea queda.
2. Abrir VSCode en el archivo con conflict. Va a verse así (resaltado en color):

   <<<<<<< HEAD
   [tu version del párrafo]
   =======
   [la version de Michel]
   >>>>>>> main

3. Decidís qué queda: tu version, la de Michel, o ambas combinadas. Borrá los marcadores <<<<<<<, =======, >>>>>>>.
4. Si dudás, abrí Claude chat: "Claude, tengo un merge conflict en .planning/stato-lavoro-os.md, mostrame las dos versiones y ayudame a decidir". Claude lee + te explica + sugiere resolución.
5. Confirmás al final:

   git add .planning/stato-lavoro-os.md
   git commit -m "merge: resolve stato-lavoro-os conflict"
   git push origin main

6. Avisás Michel: "tuve un conflict en X, lo resolví así". El verifica próximo pull.

Wedding-Templates · workflow separado

Wedding-Templates es otro repo, NO parte de sharkcode/. Reglas similares pero scope distinto.

cdwt                            # alias = cd ~/Code/Wedding-Templates
git checkout master             # NO "git checkout main" (no existe)
git pull origin master
git push origin master

Workflow practice Day 2-7 cliente fittizio

Para esercizio practice cliente fittizio "Mariposa Wedding" (Day 2-7 FLOW-DAY-1 Phase 3b):

# 1. Crear branch dedicado practice (NO tocar master directo)
cdwt
git checkout master
git pull origin master
git checkout -b noelia-mariposa-practice

# 2. Duplicar template existente (Claude lo hace por vos)
# "Claude, duplicá federica-lorenzo para cliente fittizio Mariposa Wedding palette verde menta"

# 3. Iterar + commit a tu branch
git add templates/mariposa-wedding/
git commit -m "feat(mariposa-practice): customization Noelia practice"

# 4. Push a tu branch (NO merge a master, es practice fittizio)
git push origin noelia-mariposa-practice

# 5. Cuando practice termina, branch queda como reference (Michel decide si merge o delete)

Workflow Day 30+ cliente real Wedding

Cuando Michel te asigna cliente real Wedding (post-onboarding pair-mode):

• Michel setup Supabase project + Resend API key + Vercel deploy del cliente (workflow Michel-side standard)
• Vos trabajás en branch cliente-[nombre] dedicado (NO master)
• Merge a master via PR cuando cliente approves + Michel reviewa
• Deploy via node tools/ftp-deploy.mjs o pnpm --filter cliente build + Vercel

Etsy listings · NO Git involvement

Etsy listings reales viven en Etsy seller dashboard (web), NO en Git. Cero conflict possible.

Tu workflow Etsy real Day 14+:

1. Design Canva → export PNG/PDF localmente
2. Upload Etsy seller dashboard (browser, etsy.com/your/shops/manage) → listing live
3. Backup local: guardás Canva exports + copy descrizioni in clients/noelia-etsy/listings/etsy-NNN.md + canva-exports/etsy-NNN.png
4. Commit backup al repo sharkcode (audit trail + recovery if Etsy elimina listing):

   git add clients/noelia-etsy/listings/etsy-001.md
   git add clients/noelia-etsy/canva-exports/etsy-001.png
   gc "feat(noelia-etsy): listing 001 live - wedding planner ES"
   gp                              # pull si Michel commited mientras vos trabajabas
   git push origin main

FAQ comunes

Q · Y si me olvido de hacer pull antes de push?

Git te rechaza el push con mensaje:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

NO rompe nada. Solucion: gp && git push origin main. Listo.

Q · Y si Michel hizo commit con un bug y rompió algo?

Vos no responsable. Le decís en chat: "Michel, el último commit X rompió Y". El revierte con git revert (NO force push). Vos hacés gp después de su fix.

Q · Puedo borrar branches viejos en sharkcode?

No. Branches que no creaste vos NO los borres. Si querés limpiar el tuyo (noelia-etsy-launch después de merge), preguntás a Michel primero.

Q · Y si quiero hacer un experiment crazy sin riesgo de romper algo?

Branch dedicado experiment-XYZ:

git checkout -b experiment-noelia-test
# Trabajás, commitás, push al tuo branch
# Si funciona: pedís merge a Michel
# Si NO funciona: git branch -D experiment-noelia-test (borrás solo tu branch)

Cero riesgo para Michel porque tu branch es aislado.

Q · Y si tengo dudas en general?

Claude chat. "Claude, no estoy segura si tengo que hacer pull o push primero, mostrame git status + git log + decime qué hacer". Te dice paso a paso. Día 30+ vos sabrás solo, pero primer mes Claude te ayuda en tiempo real.