Tout pareil qu'avec SVN, non ? Quand ton checkout n'est pas à jour, il faut faire un update
Je ne crois pas non. La grosse différence avec SVN c'est qu'avec ce dernier, tu n'es pas empêché de committer si les changesets portent sur des fichiers disjoints. Avec git et tous les DVCS, c'est le cas. C'est inhérent au modèle distribué. Ces fameux commits de merge que l'on se doit de filtrer pour rendre l'historique plus clair ou qui justifient l'existence du rebase.
Ceci peut paraître anodin mais ça a une conséquence importante:
Avec SVN la gestion des composants est beaucoup plus souple. Un repo SVN peut accueillir des modules disjoints et les gérer comme des projets séparés de manière transparente. On n'est pas pollué par les commits des autres tout en bossant avec du trunk dev. Ceci offre beaucoup de souplesse pour faire évoluer son architecture. A un moment, on peut incorporer du code d'un autre composant ou au contraire le séparer ... sans perdre l'historique.
Avec git, il faut faire des choix à priori en séparant les composants et utiliser les submodules (ou d’autres solutions équivalentes) avec toute leurs limitations et des problèmes à gérer si ces choix s’avéraient erronés ou si les besoins évoluent. L'autre solution est de dédier une branche par composant avec toute la complexité associée (convention de nommage sur les branches, ...).
Je conviens que ceci est assez largement compensé par le fait que la gestion par composant peut se faire au niveau binaire, mais la granularité d'un article de configuration n'a jamais été chose simple et quelquefois la gestion de composants niveau source est incontournable.
« out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation,
Grosse mauvaise foi détectée.
J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas contributeur sur le projet, je trouve quand même ta remarque assez décalée lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward". C'est assez cocasse d'ailleurs que pour dépatouiller tu confesses d'être obligé de faire appel à ton expertise. Ca prouve la simplicité du bousin. Pour alimenter la réflexion et sans attaque personnelle, voici un article (https://medium.com/@cscalfani/why-experts-make-bad-teachers-ccaed2df029b#.luyizwowj) qui amène à se questionner sur la manière de transmettre son savoir en tant qu’expert d’un domaine
Au titre des choses amusantes aussi, les milles manières de réécrire un historique en multipliant les commandes (rebabse -i, squash, amend, cherry-pick, reset --soft|mixed, ...) mais expliquer après que par contre, ils n’ont pas été foutu de séparer le checkout d'un commit et d'un fichier, en 2 commandes distinctes ou de s'accorder sur un nom de commande pour cleaner l'index et qu'il faut en passer par un reset HEAD tellement evident ... qu’un bookmark stack overflow de + pour votre collection http://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area) avec un alias à la clé.
Autre truc amusant, les explications sur les dangers des commandes qui réécrivent l’historique et qu’il faut utiliser avec précaution (amend, reset , ...) à cause des push. Alors oui, il y a le --force qui prévient. Oui comme tu l’expliques ailleurs, la force de Git c’est la gestion de son historique local et il faut expliquer au newbies qu’une branche locale c’est un peu comme son workspace git, c’est un espace privé. Mais en centralisé, il y a fallu créer des webhooks ou positionner des options git pour bloquer les conneries. Et on aimerait bien que git soit un peu plus prévenant en amont; comme par exemple des options pour limiter le reset sur commits non pushés. Evidemment ce n’est pas possible puisque git de base doit aussi supporter le mode décentralisé et que dans ce cas rien ne peut être anticipé (je ne sais pas qui a déjà cloné ma branche si je bouge ma ref).
Mais dans tout ça, ce que je trouve le plus savoureux, c'est de me remémorer ces trolls où certains disaient que le fait que git récupère une copie du dépôt en entier était un problème. Surtout pour un workflow centralisé en entreprise, ça n'était pas forcément un choix pertinent. On nous expliquait que grâce à son algo de compression ce n'était absolument pas un problème pour le transfert que le kernel en était une preuve.
Et maintenant, on prend conscience que des projets, ce ne sont pas que des fichiers source mais qu'on a besoin de jeu de données pour les test d'intégration, de stocker des binaires notamment dans le domaine du jeu (artworks) ... et que leur place est bien dans le dépôt. Ce ne sont pas des documents Word avec lesquels on explique gentiment qu'il y a d'outres outils pour ça.
Moralité depuis:
* J'ai un collègue admin qui fait la chasse aux binaires dans les dépôts et s'amuse à les cleaner à coup de bfg (comment ça l'historique d'un projet est sacré ma bonne dame ? ... Vous ne vous en servez plus, raison de service, Léon le nettoyeur va passer). En terme d’admin, on se croirait revenu au temps glorieux de Clearcase, tient.
* Git prend en charge le fait de partager un même dépôt entre plusieurs workspaces alors qu'on se moquait doucement des DVCS qui le permettaient. (Je conviens que c'est vraiment un nice to have parce qu'une recopie d'un clone en local ça coûte rien en réseau)
* Git étant surtout utilisé en centralisé (merci Github et Atlassian) et v'la tit pas qu'on nous sort du git LFS pour adresser le problème des gros fichiers. Quelle ironie du sort. A chaque checkout, on va vous expliquer qu'il faut être connecté pour récupérer la bonne version du binaire. Allez encore un petit effort et vous allez découvrir la notion de client serveur, de workspace en mode centralisé et qu'un cache pour stocker l'historique, c'est suffisant (Perforce le gère depuis le début). Ok je retire cette dernière phrase qui est de la pure provoc.
L'autre gros soucis dans le cas de workflow centralisé concerne le lock pessimiste. On a beau nous expliquer qu'un outil de gestion de version n'a pas vocation à être un outil de communication, l’argument ne passe pas. Expliquez-moi ce dont vous avez besoin, on vous expliquera comment vous en passer ! (Petit hommage à Coluche, tu nous manques). Lorsqu'on bosse avec des fichiers binaires comme des images, des fichiers qui ne proposent pas leur propre interface de merge (modèle UML, fichiers XML persistants avec une sémantique bien définies), l'argument a du mal à passer et les options --ours et --theirs du merger sont quand même un peu légères. Lorsque tu viens de te chiader l'édition d'une image et qu'un gugusse te balance une modif en même temps, y’a quand même un souci et si on vous rétorque que vous avez qu’à vous parler avant, vous pouvez aussi lui renvoyer que dans ce cas les merges ne servent à rien sur les fichiers source et il suffit de se parler et de revenir à ce bon vieux RCS. SVN avec les properties sur les types de fichiers et le svn lock le suporte au poil. Autre exemple, Talend studio (un ETL) a récemment migré de SVN vers Git pour son studio, suite forte pression client. Ils se sont retrouvés à réécrire un système de lock à part du cvs parce que les mêmes clients ne veulent pas sacrifier sur le lock pessimiste non plus.
Aujourd'hui le bilan est le suivant. Malgré ces mérites indéniables (on est tous d’accord), on se retrouve coincé avec un outil dont la vocation n'est pas le modèle centralisé. On nous explique qu'il le gère, car qui peut le plus peut le moins. Mais du coup des choses basiques qui pourraient améliorer ce workflow seraient incompatibles avec les autres modèles de workflow. Alors on voit émerger de plus en plus de solutions de contournement. Soit, mais s'il vous plait, convenez que SVN est assez adapté pour ce besoin et non, git de base n'est pas toujours aussi adéquat ni en termes de simplicité ni en termes de besoins. A côté de ça, personne ne souhaite revenir sur le confort de rajouter un remote pour bosser sur le même projet entre 2 organisations séparées ou encore la possibilité d'accueillir des contributions ponctuelles avec des pull request mais on est bien au delà d'un simple projet centralisé dans une entreprise. Quand à la possibilité de réécrire son historique avant de pusher, top de choix tue le choix. Pas toujours facile de s'accorder sur la bonne granularité du commit. Entre ceux qui visent la simplicité et veulent pouvoir cherry-picker un seul commit pour reporter une feature, ceux qui veulent pouvoir relire l'historique par petits incréments et trouvent que c'est plus simple en cas de rebase, les protagonistes de la feature branch.
Et voilà encore un nouvel animal de foire, le git series ... Si ce n'est pas du cargo cult, en tout cas ça y ressemble parfois.
Pas facile de faire comprendre un newbie qui vient de découvrir les branches, les pull request vendues par les marchands de rêves à la Github/Bitbucket et qu'il veut vous en fourguer partout, que ça contrevient un des principes de bases de l'agilité: l'intégration continue. quPas facile de lui faire comprendre que les features branches n'ont rien d'agile (http://martinfowler.com/bliki/FeatureBranch.html) et venir le voir pleurer lorsqu'il a refactoré comme un porc et se trouve comme un con avec un big bang merge et qu'on doit se taper de le dépanner à coup de stratégies de merge et d'ajustement du "threshold" dans le find-renames.
Avec de grands pouvoirs, viennent de grandes responsabilités...
[^] # Re: Rrrr Zzzz
Posté par El Titi . En réponse au journal Git Rev News: la newsletter de Git, et sondage pour utilisateurs de Git. Évalué à 8.
Je ne crois pas non. La grosse différence avec SVN c'est qu'avec ce dernier, tu n'es pas empêché de committer si les changesets portent sur des fichiers disjoints. Avec git et tous les DVCS, c'est le cas. C'est inhérent au modèle distribué. Ces fameux commits de merge que l'on se doit de filtrer pour rendre l'historique plus clair ou qui justifient l'existence du rebase.
Ceci peut paraître anodin mais ça a une conséquence importante:
Avec SVN la gestion des composants est beaucoup plus souple. Un repo SVN peut accueillir des modules disjoints et les gérer comme des projets séparés de manière transparente. On n'est pas pollué par les commits des autres tout en bossant avec du trunk dev. Ceci offre beaucoup de souplesse pour faire évoluer son architecture. A un moment, on peut incorporer du code d'un autre composant ou au contraire le séparer ... sans perdre l'historique.
Avec git, il faut faire des choix à priori en séparant les composants et utiliser les submodules (ou d’autres solutions équivalentes) avec toute leurs limitations et des problèmes à gérer si ces choix s’avéraient erronés ou si les besoins évoluent. L'autre solution est de dédier une branche par composant avec toute la complexité associée (convention de nommage sur les branches, ...).
Je conviens que ceci est assez largement compensé par le fait que la gestion par composant peut se faire au niveau binaire, mais la granularité d'un article de configuration n'a jamais été chose simple et quelquefois la gestion de composants niveau source est incontournable.
J'ai eu à traiter une migration SVN d'un projets qui hébergeait des services. Ce fut un véritable casse-tête.
Pas convaincu ? Alors lisez pourquoi Google assume ce choix
http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
Grosse mauvaise foi détectée.
J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas contributeur sur le projet, je trouve quand même ta remarque assez décalée lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward". C'est assez cocasse d'ailleurs que pour dépatouiller tu confesses d'être obligé de faire appel à ton expertise. Ca prouve la simplicité du bousin. Pour alimenter la réflexion et sans attaque personnelle, voici un article (https://medium.com/@cscalfani/why-experts-make-bad-teachers-ccaed2df029b#.luyizwowj) qui amène à se questionner sur la manière de transmettre son savoir en tant qu’expert d’un domaine
Au titre des choses amusantes aussi, les milles manières de réécrire un historique en multipliant les commandes (rebabse -i, squash, amend, cherry-pick, reset --soft|mixed, ...) mais expliquer après que par contre, ils n’ont pas été foutu de séparer le checkout d'un commit et d'un fichier, en 2 commandes distinctes ou de s'accorder sur un nom de commande pour cleaner l'index et qu'il faut en passer par un reset HEAD tellement evident ... qu’un bookmark stack overflow de + pour votre collection http://stackoverflow.com/questions/19730565/how-to-remove-files-from-git-staging-area) avec un alias à la clé.
Autre truc amusant, les explications sur les dangers des commandes qui réécrivent l’historique et qu’il faut utiliser avec précaution (amend, reset , ...) à cause des push. Alors oui, il y a le --force qui prévient. Oui comme tu l’expliques ailleurs, la force de Git c’est la gestion de son historique local et il faut expliquer au newbies qu’une branche locale c’est un peu comme son workspace git, c’est un espace privé. Mais en centralisé, il y a fallu créer des webhooks ou positionner des options git pour bloquer les conneries. Et on aimerait bien que git soit un peu plus prévenant en amont; comme par exemple des options pour limiter le reset sur commits non pushés. Evidemment ce n’est pas possible puisque git de base doit aussi supporter le mode décentralisé et que dans ce cas rien ne peut être anticipé (je ne sais pas qui a déjà cloné ma branche si je bouge ma ref).
Mais dans tout ça, ce que je trouve le plus savoureux, c'est de me remémorer ces trolls où certains disaient que le fait que git récupère une copie du dépôt en entier était un problème. Surtout pour un workflow centralisé en entreprise, ça n'était pas forcément un choix pertinent. On nous expliquait que grâce à son algo de compression ce n'était absolument pas un problème pour le transfert que le kernel en était une preuve.
Et maintenant, on prend conscience que des projets, ce ne sont pas que des fichiers source mais qu'on a besoin de jeu de données pour les test d'intégration, de stocker des binaires notamment dans le domaine du jeu (artworks) ... et que leur place est bien dans le dépôt. Ce ne sont pas des documents Word avec lesquels on explique gentiment qu'il y a d'outres outils pour ça.
Moralité depuis:
* J'ai un collègue admin qui fait la chasse aux binaires dans les dépôts et s'amuse à les cleaner à coup de bfg (comment ça l'historique d'un projet est sacré ma bonne dame ? ... Vous ne vous en servez plus, raison de service, Léon le nettoyeur va passer). En terme d’admin, on se croirait revenu au temps glorieux de Clearcase, tient.
* Git prend en charge le fait de partager un même dépôt entre plusieurs workspaces alors qu'on se moquait doucement des DVCS qui le permettaient. (Je conviens que c'est vraiment un nice to have parce qu'une recopie d'un clone en local ça coûte rien en réseau)
* Git étant surtout utilisé en centralisé (merci Github et Atlassian) et v'la tit pas qu'on nous sort du git LFS pour adresser le problème des gros fichiers. Quelle ironie du sort. A chaque checkout, on va vous expliquer qu'il faut être connecté pour récupérer la bonne version du binaire. Allez encore un petit effort et vous allez découvrir la notion de client serveur, de workspace en mode centralisé et qu'un cache pour stocker l'historique, c'est suffisant (Perforce le gère depuis le début). Ok je retire cette dernière phrase qui est de la pure provoc.
L'autre gros soucis dans le cas de workflow centralisé concerne le lock pessimiste. On a beau nous expliquer qu'un outil de gestion de version n'a pas vocation à être un outil de communication, l’argument ne passe pas. Expliquez-moi ce dont vous avez besoin, on vous expliquera comment vous en passer ! (Petit hommage à Coluche, tu nous manques). Lorsqu'on bosse avec des fichiers binaires comme des images, des fichiers qui ne proposent pas leur propre interface de merge (modèle UML, fichiers XML persistants avec une sémantique bien définies), l'argument a du mal à passer et les options --ours et --theirs du merger sont quand même un peu légères. Lorsque tu viens de te chiader l'édition d'une image et qu'un gugusse te balance une modif en même temps, y’a quand même un souci et si on vous rétorque que vous avez qu’à vous parler avant, vous pouvez aussi lui renvoyer que dans ce cas les merges ne servent à rien sur les fichiers source et il suffit de se parler et de revenir à ce bon vieux RCS. SVN avec les properties sur les types de fichiers et le svn lock le suporte au poil. Autre exemple, Talend studio (un ETL) a récemment migré de SVN vers Git pour son studio, suite forte pression client. Ils se sont retrouvés à réécrire un système de lock à part du cvs parce que les mêmes clients ne veulent pas sacrifier sur le lock pessimiste non plus.
Aujourd'hui le bilan est le suivant. Malgré ces mérites indéniables (on est tous d’accord), on se retrouve coincé avec un outil dont la vocation n'est pas le modèle centralisé. On nous explique qu'il le gère, car qui peut le plus peut le moins. Mais du coup des choses basiques qui pourraient améliorer ce workflow seraient incompatibles avec les autres modèles de workflow. Alors on voit émerger de plus en plus de solutions de contournement. Soit, mais s'il vous plait, convenez que SVN est assez adapté pour ce besoin et non, git de base n'est pas toujours aussi adéquat ni en termes de simplicité ni en termes de besoins. A côté de ça, personne ne souhaite revenir sur le confort de rajouter un remote pour bosser sur le même projet entre 2 organisations séparées ou encore la possibilité d'accueillir des contributions ponctuelles avec des pull request mais on est bien au delà d'un simple projet centralisé dans une entreprise. Quand à la possibilité de réécrire son historique avant de pusher, top de choix tue le choix. Pas toujours facile de s'accorder sur la bonne granularité du commit. Entre ceux qui visent la simplicité et veulent pouvoir cherry-picker un seul commit pour reporter une feature, ceux qui veulent pouvoir relire l'historique par petits incréments et trouvent que c'est plus simple en cas de rebase, les protagonistes de la feature branch.
Et voilà encore un nouvel animal de foire, le git series ... Si ce n'est pas du cargo cult, en tout cas ça y ressemble parfois.
Pas facile de faire comprendre un newbie qui vient de découvrir les branches, les pull request vendues par les marchands de rêves à la Github/Bitbucket et qu'il veut vous en fourguer partout, que ça contrevient un des principes de bases de l'agilité: l'intégration continue. quPas facile de lui faire comprendre que les features branches n'ont rien d'agile (http://martinfowler.com/bliki/FeatureBranch.html) et venir le voir pleurer lorsqu'il a refactoré comme un porc et se trouve comme un con avec un big bang merge et qu'on doit se taper de le dépanner à coup de stratégies de merge et d'ajustement du "threshold" dans le find-renames.
Avec de grands pouvoirs, viennent de grandes responsabilités...