Il faut utiliser des codes couleurs ANSI : http://pueblo.sourceforge.net/doc/manual/ansi_color_codes.html

Pour que ça marche il faut rajouter \033 devant le [, ce qui donne donc : \033[31m pour afficher le texte qui suit en rouge.
Ensuite il faut aussi bien penser à restaurer la couleur initiale du texte, sinon tout le reste sera écrit en rouge : \033[0m à la fin du texte.
Et sous bash, il faut ajouter l'option -e à echo pour que les codes couleurs ANSI soient pris en compte (cette option n'existe pas avec sh, les codes couleurs sont pris en compte par défaut)

Ce qui nous donne donc : echo -e "\033[31m Du texte rouge !\033[0m"

OVH utilise (depuis peu il me semble, je n'avais jamais observé ce comportement auparavant) un cache pour les contenus statiques des pages webs hébergés sur ces serveurs mutualisés. C'est compréhensible parce que ça diminue nettement la charge sur les serveurs web, mais ça donne lieu à des trucs un peu bizarre si vous déployez directement vos pages sur le mutualisé pour le dev (ce que moi je fais quand je suis sur une machine qui n'est pas mon PC) : vous mettez bien à jour le CSS (ou l'image) et pourtant votre style ne change pas. Vous essayez de vider le cache du navigateur mais rien ne marche, puis vous vous rendez compte que c'est bien l'ancien fichier que le serveur vous envoie. Vous pensez alors que votre client FTP a fait de la merde et vous ré-uploadez mais ça merde toujours … Bref c'est un comportement qu'il vaut mieux connaître sinon c'est une bonne prise de tête en perspective ^^.
Le cache expire au bout de 15 minutes, du coup il vaut mieux être patient :p

git diff A..B <=> git diff A B

tandis que git diff A...B <=> git diff $(git merge-base A B) B

Des schémas explicatifs encore plus clairs sont disponibles ici : http://stackoverflow.com/questions/7251477/what-are-the-differences-between-double-dot-and-triple-dot-in-git-dif

Pour trouver l’ancêtre commun de 2 commits. (ou plus mais dans ce cas là c'est plus compliqué que simplement l’ancêtre commun)

find . -type f -name "*.js" -not -path node_modules -exec js-beautify -r {} \;

(en excluant le répertoire node_modules)

p.s. c'est aussi un très bon exemple d'utilisation de la fonction "find"

Un must have ! Cet article explique de façon claire et détaillées tout ce qu'il faut savoir sur les merge et les rebase dans git

(oui je suis en mode mémo git en ce moment ^^)

git tag -a tag-name -m 'Here is a tag message'

Et bien penser à faire git push origin tag-name après, parce que sinon les tags ne sont pas pushé.

Comme c'est la 3ème fois que ça arrive autour de moi en à peine 2 semaine, je vais noter ça ici ça peut toujours resservir.

Pour annuler un git add, il faut faire un git reset HEAD (ce qui nous ramène au dernier commit, que je vais appeler commit 1) mais les débutants (moi le premier il y a 2 semaines) ont semble-t-il envie de faire git reset HEAD^ à la place (qui ramène en fait à l'avant dernier commit commit 0). Le problème de git reset c'est que ça ne se contente pas de bouger l'état courant (le HEAD), ça bouge carrément la dernière position de la branche sur laquelle on était. Du coup un git checkout ma-branche me ramènera maintenant au commit 0, et mon commit 1 est maintenant orphelin, rattaché à aucune branche. Il n’apparaît d’ailleurs plus nulle par dans le git log.

Comment faire alors ?

Déjà pour retrouver son commit, il est bon de connaitre la commande git reflog qui garde un historique de tous les déplacement de l'utilisateur sur git. Il sera donc facile de retrouver le hash du commit porté disparu.

Une fois qu'on a le hash, pour rattacher ce commit à la branche dont il vient, il suffit de faire git merge hash-de-mon-commit depuis la branche.

/!\ git checkout hash-de-mon-commit suivi de git merge ma-branche ne marchera pas. Le commit étant un descendant direct de la branche dira qu'il n'y a rien à récupérer dans la branche.

Les keymaps des packages atom fonctionnent avec des sélecteurs CSS, et à sélecteur égal, c'est la keymap utilisateur qui l'emporte sur la keymap des packages. Seulement voilà, si le package a enregistré sa règle avec un sélecteur plus fort que le votre vous êtes marron :
Exemple :
Keymap d'un package :
'.workspace .editor':
'ctrl-alt-o': 'action-package'

Votre Keymap :
'.workspace':
'ctrl-alt-o': 'votre-action'

Comme le sélecteur CSS du package utilise 2 classes, il est plus fort que le votre avec une seule classe, donc il n'est pas surchargé par votre keymap. Si on ne connais pas le CSS, ce comportement n'est pas forcément intuitif, d'autant que ce n'est vraiment expliqué clairement nulle part ...