Sincronització de branques a git

És box-populi que treballar amb branques amb git és una delícia ja que ho facilita moltíssim: és molt ràpid i les eines que et posa a disposició per treballar-hi fan que sigui molt recomanable fer-ho per a qualsevol canvi que es vulgui fer en el codi d’una aplicació.

Ara bé, quan ja has fet els canvis que volies fer-hi com els sincronitzes cap a la branca master1 ?

Tens dues opcions, la que utilitzava jo fins ara:

git checkout master
git diff –stat master..BRANCA_DEV
git merge master..BRANCA_DEV
git push

Amb això el que obtenim és que agafem tots els canvis que hi ha a BRANCA_DEV respecte de master i els mescla. A més a més per deixar-ne constància en fa un commit final amb la típica frase2Merge branch ‘BRANCA_DEV’ into master“.

Ara bé, hi ha una manera més bonica i més elegant de fer-ho, rebase:

git checkout master
git rebase BRANCA_DEV
git pull
git push

Amb això el que estem fent és agafar els canvis de la branca BRANCA_DEV i els col·loca, en bloc, abans dels canvis que tinguem fets a la branca master. Això vol dir que si partim d’un commit X i fem tres canvis a la branca BRANCA_DEV i dos canvis a la branca master, quan executem les ordres de sobre el farà el git és reiniciar els commits fins al commit X, aplicar consecutivament els 3 commits de BRANCA_DEV i finalment un cop fet això aplicarà els nostres dos canvis a la pròpia branca master.

D’aquesta manera, sigui quin sigui el mètode utilitzat per sincronitzar les branques ja tindreu una manera molt fàcil de treballar amb diverses branques alhora, etc etc

  1. Així és com es diu la branca principal a git. []
  2. Com tot en el git es pot canviar []

canviar el títol del terminal

Resulta que a la feina tenim uns quants servidors virtuals per a diferents propòsits i com que un era amb CentOS i d’altres amb Debian un dia vaig adonar-me que quan em connectava al CentOS se’m canviava el títol del terminal però en canvi en connectar-me als Debian no.

Així que investigant una mica he descobert que hi ha la variable PROMPT_COMMAND que et permet canviar el títol, de manera que per exemple si poses al ~/.bashrc:

PROMPT_COMMAND=’echo -ne “\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007″‘

Et posarà com a títol el nom d’usuari, l’ordinador on estàs i el camí on estàs actualment.

com enganxar al Vim sense que es re-formati

Segur que els que utilitzeu el Vim ja n’heu buscar la solució ja que realment és molt molest.

Si aneu a una pàgina web i en copieu el codi font d’un tros de programa, per exemple:

Us trobareu que un cop enganxat al terminal queda tot el codi reformatat:

Per sort amb el Vim li pots dir que no reformati el codi:

El truc està en que abans d’enganxar al terminal ens posem en mode control i establim l’opció paste) o sigui, la seqüència és:

  • (obres el fitxer)
  • Passes a mode ordre (amb la tecla Esc)
  • escrius :set paste
  • tornes a mode edició (amb la tecla i)
  • ja pots fer un Ctrl+Maj+V per enganxar el que tinguis al porta-retalls

Llestos ja tenim un bon tros de codi que no hem de picar i que a més continua ben formatat :)


cada connexió (ssh) té la seva configuració

No us heu cansat mai de teclejar ssh usuari@nom-interminable-de-la-maquina-hi-ha-sobre.domini ?

Doncs com en tot en el món linux té el seu fitxer de configuració: ~/.ssh/config (man ssh_config).

És tan senzill com tres línies:

Host nom-curt

HostName nom-del-servidor.com

User usuari

Un cop escrit això de sobre (canviant les cursives clar) ja podreu teclejar ssh nom-curt quan en realitat estaríeu teclejant ssh usuari@nom-del-servidor.com.

Sembla una petita diferència oi? Però penseu en els casos en que teniu més d’una clau pública1 o qualsevol altre opció que heu d’especificar per connexió!

No hi ha dia que em deixi de sorprendre i trobar encara més útil l’OpenSSH!

  1. La de la feina, la del servidor de casa, la del projecte on esteu col·laborant, la d’accés a repositoris de codi … []

git show(1)

No us heu trobat mai amb la necessitat de veure els canvis que s’han fet en un commit? Res més senzill que fer un git log per agafar el SHA1 del commit en qüestió i després fer un git show SHA1.

Evidentment com qualsevol altre ordre de git pot fer molt més que només mostrar els canvis fets en un commit, ja que la descripció que se’n dóna en fer un git help show és: Mostra diversos tipus d’objectes.

administració de servidors i git

Fins que no proves les coses no te n’adones de lo difícil, o fàcil, que és fer-les…

Avui havia de fer uns canvis a un dels servidors de la feina i com que eren temes de configuració … cd /etc

Però abans de prémer cap més tecla m’ho he pensat dues vegades i he teclejat unes quantes ordres ben senzilles i  molt útils de cara al futur:

Control de versions de la configuració d’un servidor

Sembla que pugui ser una cosa difícil, que requereixi molt de temps i que sigui complex de mantenir oi? Doncs res més senzill que fer:

cd /etc
git init
(opcionalment vim .gitignore per excloure els fitxers que no volem versionar)
git add -A
git commit -m"Configuració inicial que funciona del servidor"

Només amb aquestes senzilles ordres ja tenim tot el directori /etc versionat amb git. A partir d’ara qualsevol canvi a qualsevol fitxer que estigui dintre de /etc ens sortirà amb un git status i quan haguem fet les proves necessàries per assegurar que els canvis són correctes ja podrem fer un git commit FITXER1 FITXER2 -m”Missatge” per tenir controlada una nova revisió dels fitxers.

Ara ja no hi ha excusa per dir que s’ha perdut alguna configuració o que s’ha espatllat algun servei del servidor, sempre tindràs un git checkout o un git reset –hard HEAD per tornar a una versió dels fitxers de configuració correcta :)

Fonaments d’Android

Aquests dies estic començant a mirar-me tot el tema d’Android i per sort meva tenen un document, que per a mi, és molt important: Application Fundamentals.

Allà no t’explica cap truc per fer que la teva aplicació sigui perfecta, ni tan sols t’explica com l’has d’estructurar, però en canvi et vomita totes les paraulotes de la terminologia que es fa servir a Android. Per exemple: no fas crides a classes per crear una nova pantalla, sinó que fas un Intent. Totes les necessitats de hardware i software externs al teu projecte han d’estar escrits en un fitxer xml…

Evidentment llegint això no serveix per crear aplicacions, però sense llegir-ho ho passaràs força malament :)

Alguns consells sobre què més llegir o quines pàgines consultar per quan hi hagin dubtes sobre Android?

git stash

Una de les primeres coses que descobreixes quan utilitzes git és que de la mateixa manera que un mediawiki, per posar un exemple, hi ha mil i una maneres de treballar-hi:

Tot amb branques, arbres remots a github, via pedaços (com se solia anar amb subversion i cvs) …

De manera que igual com amb un mediawiki el més important és definir una bona guia d’estil, les plantilles i el sistema de categorització, treballant amb el git, el més important és definir dintre de l’equip de treball un bon cicle de treball per tal que no hi hagi diverges

I és aquí on entra l’ordre git stash.

Un exemple ben fàcil: tens canvis a 5 fitxers diferents, fas un commit per a tres d’ells perquè els altres dos encara no estan llestos per enviar.  Si en aquell moment vols fer un git pull –rebase perquè el servidor de git és un servidor central i vols agafar els últims canvis i aplicar-hi els teus commits locals a sobre de les últimes actualitzacions, el git no et deixarà fer-ho, ja que hi ha canvis sense estar en un commit.

No pots fer-ne un commit perquè no estan acabats, de manera que el que pots fer és un git stash, que senzillament desa els canvis que no estan a cap commit i et deixa l’arbre sense cap fitxer que no estigui en un commit, de manera que ja pots fer un git pull –rebase i si tot va bé un git push per enviar els teus commits locals.

Ja només et queda fer un git stash pop per recuperar els canvis que tens que no estan a cap commit i continuar treballant tranquilament :)

Evidentment, com tota eina de git, el git stash et permet fer moltíssimes coses més, de fet per tal com es recupera la sessió desada (git stash pop) ja podeu veure que el git stash funciona com una pila, de manera que pots tenir tants stash com necessiteu1 i aplicar-los a altres branques, o crear branques a partir dels stash, etc etc …

  1. No exempt de perill que després no funcionin sobre el commit en el que esteu treballant []

treure tabulacions i espais finals dels fitxers

Fent neteja dels fitxers m’he trobat amb la poca grata sorpresa que tenia l’XCode1 configurat perquè fes servir tabulacions en comptes d’espais…

De manera que una mica de cerca per Internet i dues petites joies per facilitar-nos el dia:

  • L’eina expand permet canviar tabulacions per espais (i a l’inrevés si algú ho necessita)
  • He trobat un script per sed per suprimir els espais finals (compte que si no vigileu es menja també les t finals!)
  1. L’EID que has de fer servir per fer aplicacions per a l’iPhone []

Permisos per compartir un repositori de git

Un dels problemes de tenir un repositori en un servidor central és com de costum el tema dels permisos, per una banda has de tenir els usuaris creats en local, afegir-los en el mateix grup perquè cadascú pugui accedir als repositoris i finalment un cop està tot apunt tens el problema (amb solució!) de que quan algú fa un commit la resta no en poden fer ja que s’han canviat els permisos.

A primer cop d’ull penses que això amb un hook de git i un script que faci un chown ja n’hi pot haver prou, després ho rumies una mica més i penses que no hauria de ser tant complicat i arribes a la idea que l’umask serà el teu amic … però al final cerques una mica per Internet i et trobes amb una solució molt més elegant:

$ git repo-config core.sharedRepository true

Amb aquesta senzilla ordre executada per a tots i cadascun dels repositoris que vulguis compartir entre més d’un desenvolupador i llestos, a programar que és el que ens agrada.