En résumé : on peut faire un cherry-pick d'un commit d'une branche dans une autre, puis faire un merge de ces 2 branches et cela devrait fonctionner sans duplication. Sinon, il faudra régler le conflit à l'ancienne.

Pour éviter aussi la duplication dans l'historique, on peut utiliser "rebase".

Pour utiliser Gitlab CI :
http://docs.gitlab.com/ce/ci/variables/README.html
https://docs.gitlab.com/ce/user/project/new_ci_build_permissions_model.html

Something wrong

git reflog
# you will see a list of every thing you've done in git, across all branches!
# each one has an index HEAD@{index}
# find the one before you broke everything
git reset HEAD@{index}
# magic time machine

I accidentally committed to the wrong branch!

# undo the last commit, but leave the changes available
git reset HEAD~ --soft
git stash
# move to the correct branch
git checkout name-of-the-correct-branch
git stash pop
git add . # or add individual files
git commit -m "your message here"
# now your changes are on the correct branch

Oui, quelqu'un paie un nom de domaine chaque année pour ça. Merci quand même :-)

Excellent petit outil pour browser des repo Git via le Web.

A utiliser avec parcimonie, mais c'est bien pratique.

• Quand je fusionne une branche…
  Si elle est purement locale et temporaire, je m’assure qu’elle n’apparaît pas dans le graphe final de l’historique en faisant un fast-forward merge, ce qui peut nécessiter un rebase au préalable.
  Si elle a une sémantique claire et documentée, je m’assure qu’elle apparaîtra clairement dans le graphe de l’historique, du début à la fin, en garantissant un true merge.
• Quand je m’apprête à pusher mon travail local, je nettoie mon historique local d’abord pour partager un historique propre, au cordeau.
• Quand je me vois refuser le push parce qu’un travail complémentaire a été pushé entre-temps, je rebase sur la branche distante à jour pour éviter de polluer le graphe par des tas de micro-merges malvenus.

Y a plus qu'à !

Pas mal du tout ces alias Git !

Eheh, génial !
(via http://bookmarks.cdetc.fr/?FLNPLQ)

Bien pratique ;-)

Depuis que je suis obligé de jouer avec les repository "remote" avec Git (puisqu'on je suis sur un projet qui n'a pas encore de repository remote centralisé à la Github, donc on s'échange des des repository "bare" par email), je maîtrise bien mieux Git ! Et je comprends beaucoup mieux ce que signifie réellement un pull/push, même un commit et les 3 états possibles des fichiers locaux. C'est incroyable de souplesse ce système.

Du coup j'ai traduit et agrémenté l'article.

En parlant de Pro Git : ce lien permet de télécharger la version française en PDF, ePub, et autre (version de mars 2012, ça a peut-être changé depuis).
La version "officielle" ne propose que la version anglaise : http://git-scm.com/book

A lire...

Ok, I will do that ;-)