URL: https://linuxfr.org/users/crev/journaux/git-workflow-rebase-conflits-et-role-d-integrateur Title: Git workflow, rebase, conflits et rôle d'intégrateur Authors: CrEv Date: 2014年12月02日T13:44:37+01:00 License: CC By-SA Tags: git et workflow Score: 35 'jour 'nal Depuis quelques temps, à l'occasion d'un nouveau projet (au boulot) avec mes collègues j'ai mis en place un nouveau workflow git. Vous savez, un truc qui défini comment on gère les branches, les rebases, les fusions, le nommage des branches, etc. En gros, le workflow est le suivant : - tout est réalisé dans des branches - les branches sont préfixées (exemple `refactor/copter_param`, `feature/fences`, `bug/landing`) pour les retrouver facilement - aucun commit directement dans master - pas de branches de prod, maintenance, etc - `master` est la branche stable depuis laquelle on crée les versions - une branche d'intégration existe pour faciliter les tests (j'y reviens) - les branches sont toujours rebasées depuis `integ` puis fusionnées en _"no fast forward"_ - une fois les tests validés dans integ, on merge dans master (soit en _fast forward_ si tout est bon à prendre, soit en réintégrant branche par branche) En gros tout ceci a pour objectif principal d'avoir un historique toujours très lisible. L'ensemble des modifications liées à une fonctionnalité est très lisible. Il est "facile" (autant que possible) de supprimer une fonctionnalité (il suffit d'inverser un commit de merge). (Si vous voulez plus de détails sur le pourquoi du comment c'est [par ici][blog]) Dans un monde idéal c'est super. Franchement. Avant on avait un historique, comment dire... horrible, des merges dans tous les sens, etc. Aujourd'hui on a un truc lisible : ![Avant - Après](http://media.tumblr.com/fca561a277b830ac3c5fac40f10bda44/tumblr_inline_nflo1khSyE1sv6muh.png)> Bon c'est bien joli tout ça, mais pourquoi tu nous racontes ça alors ? Le problème c'est qu'on est pas toujours dans un monde idéal. En premier lieu, je bosse dans un secteur spécial : c'est du code embarqué pour des 'ti nappareils avec des hélices qui peuvent voler dans le ciel. L'une des conséquences (associée à une base de code, comment dire poliment..., genre si j'attrape le gars qui l'a écrit je lui fais réécrire le noyau linux en [whitespace][] avec un écran monochrome) c'est que parfois nos tests unitaires (et autres) passent sur notre intégration continue, et pour autant les essais en vol ne sont pas concluant. Ça introduit une certaine latence entre le moment où on développe, le moment où on passe en CI et le moment où on valide réellement un développement. D'où la notion de branche d'intégration. La branche d'intégration est une version "à tester" qui, si tout se passe bien, peut devenir stable (master). Mais qui si ça ne se passe pas bien peut être supprimée et refaite suivant les résultats. Evidemment si on pouvait jouer des tests sur toutes les branches et être certains du résultat, il n'y aurait pas de problème ;-) Le problème résultant c'est que parfois il faut "rouvrir" les branches (enlever le commit de fusion), modifier la branche (corriger), re-fusionner. Et c'est quand même assez fastidieux. Et l'autre problème est que, pour des questions de lisibilité, on utilise beaucoup le rebase. Oui mais ça veut parfois dire des conflits un peu compliqués et surtout fastidieux. Même avec git rerere. Pour ce genre de raisons, une personne est aujourd'hui dédiée à la fusion dans les branches d'intégration et `master`. Tous les autres bossent dans leurs branches. Ça simplifie un peu le boulot global, mais c'est pas terrible. Alors j'en viens à vous questionner, chers linuxfriens adeptes de Git (mais ça marche aussi avec Mercurial). Vous arrive-t-il de bosser avec des rôles d'intégrateurs / fusionneurs Git ? Comment éviter ce type de situation ? Abandonner le rebase au prix d'un historique moins lisible ? Est-il encore temps de retourner sous svn ? [blog]: http://blog.sogilis.com/post/104148375576/notre-workflow-git-pourquoi-comment "Notre workflow Git, pourquoi, comment" [whitespace]: http://fr.wikipedia.org/wiki/Whitespace

AltStyle によって変換されたページ (->オリジナル) /