Le topic de la programmation: Et envoyez des sioux!

[gros_bidule]

Au cas où : tu sais squasher avec git ? (et good news, les IDE savent enfin le faire)
Ca change la vie, un peu comme le burger au camembert pané
Les worktrees un peu aussi.

[Orhin]

et good news, les IDE savent enfin le faire

Ça fait quand même un petit bout de temps que c'est le cas chez Jetbrains.

Mais voilà, comme les vrais j'apprécie juste un petit Meld à côté pour les diffs et le tour est joué.

La GUI c'est quand même aussi pratique pour faire des stage partiel de fichier.

[gros_bidule]

Ça fait quand même un petit bout de temps que c'est le cas chez Jetbrains.

Pas tant que ça, grosso-modo 1 an, 2 grand max. Auparavant, le squash était proposé lors d'un rebase interactif uniquement. Depuis quelques versions, on peut enfin simplement aller dans l'historique git, sélectionner des commits, et paf squash
Jusque là j'utilisais SmartGit (excellent produit au passage) pour le faire. Bcp de monde a râlé sur le youtrack pour que JetBrains finisse par se mettre à niveau, et il aura fallu du temps.

[vv221]

La GUI c'est quand même aussi pratique pour faire des stage partiel de fichier.

git add --patch

[Orhin]

Pas tant que ça, grosso-modo 1 an, 2 grand max. Auparavant, le squash était proposé lors d'un rebase interactif uniquement. Depuis quelques versions, on peut enfin simplement aller dans l'historique git, sélectionner des commits, et paf squash
Jusque là j'utilisais SmartGit (excellent produit au passage) pour le faire. Bcp de monde a râlé sur le youtrack pour que JetBrains finisse par se mettre à niveau, et il aura fallu du temps.

Ah oui je pensais que tu parlais du squash en rebase interactif, dans ce cas my bad.

git add --patch

Ouais enfin avoir un diff complet de ton fichier sur lequel tu peux cocher/décocher à la volée ce que tu veux commit, c'est quand même un poil plus pratique et ergonomique.

[Sariyah]

Salut les canards,

C'est un peu l'angoisse là, est-ce que quelqu'un aurait un Mac avec Xcode d'installer svp ? Grosso modo je dois envoyer mon projet et je n'arrive plus à l'ouvrir. Il est tout petit (6,42mo) j'ai l'impression que le Mac Book de ma femme (mid-2012) veut plus..

Je voudrais juste m'assurer qu'il run.

edit : Ah non c'est bon en fait, quelle panique

[deathdigger]

Au cas où : tu sais squasher avec git ? (et good news, les IDE savent enfin le faire)
Ca change la vie, un peu comme le burger au camembert pané
Les worktrees un peu aussi.

Nope, je ne sais même pas ce que c’est
Pour le moment, j’en suis à pull, push et commit. J’ai eu à resolve un conflit, je l’ai fait dans vscode.

[Nilsou]

Tu peux le faire avec meld sinon, ou winmerge, c'est plus simple si on ne veut pas passer par des IDE.

Sinon le seul outil git (en plus de git lui même) que je trouve indispensable c'est une arborescence visuelle des branches, comme celle construites sur l'interface d'un gitlab.

[Orhin]

Tu peux le faire avec meld sinon, ou winmerge, c'est plus simple si on ne veut pas passer par des IDE.

Ben après l'intérêt de passer par ton IDE c'est que t'as accès à tes outils d'analyse de code/lint/etc dans ta fenêtre de résolution de conflit/merge.

[vv221]

Ouais enfin avoir un diff complet de ton fichier sur lequel tu peux cocher/décocher à la volée ce que tu veux commit, c'est quand même un poil plus pratique et ergonomique.

Question d’habitude je suppose. Je préfère largement éditer le diff dans vim comme le propose git add -p en console.

[vectra]

Ouais enfin avoir un diff complet de ton fichier sur lequel tu peux cocher/décocher à la volée ce que tu veux commit, c'est quand même un poil plus pratique et ergonomique.

trve savent.
Je ne te remercierai jamais assez de m'avoir recommandé de sauter le pas quand Jetbrains vendait ses licences à 50%.

[Nilsou]

Ben après l'intérêt de passer par ton IDE c'est que t'as accès à tes outils d'analyse de code/lint/etc dans ta fenêtre de résolution de conflit/merge.

C'est vrai mais dans ce cas, autant tout faire avec l'IDE, remontées comprise...

- - - Mise à jour - - -

Ouais enfin avoir un diff complet de ton fichier sur lequel tu peux cocher/décocher à la volée ce que tu veux commit, c'est quand même un poil plus pratique et ergonomique.

Vous êtes au courant qu'il existe la commande difftool ?

[gros_bidule]

Ouiiiii ^^ mais difftool ne corrige pas les imports, ne détecte pas les erreurs de syntaxe, etc. Le faire en 3 colonnes dans un bon IDE ça a son petit intérêt
Du confort quoi. Mais je comprends que certains préfèrent le caleçon clouté, je ne juge pas.
Reste que c'est à cause de gens comme vous (en réalité pas vraiment, je sais bien) que nos boss ne veulent pas payer de licences IntejjiJ. Ducon il travaille est heureux sous Vim. Tss...

[Anonyme20240202]

J'ai converti absolument tous les fans hardcore de Vim à Jetbrains dans ma boite. Ils me remercient maintenant et sont très satisfaits. En plus y'a même un mode Vim dans Jetbrains si tu veux garder un peu le flow Vim.

Tu peux pas te passer d'un bon IDE si tu veux être efficace à mon avis. Notamment très utile sur les codebases existantes et rarement immaculées, cas classique en entreprise.

Perso pour Git j'ai une approche très minimaliste, je parle pour le cas d'utilisation dans une équipe relativement compact, pas gros projet open source international.

En gros j'essaye de me restreindre à:
clone (recursive), fetch/pull
git submodule init/add
création de branche locale, git branch
status, diff, git add, git commit, git push

Trunk based development donc une seule branche (master/main)

Avec une équipe bien synchronisée les merges sont extrêmement rares ou triviaux quand ils se produisent. L'historique est extrêmement lisible, et on peut se concentrer sur l'important: la qualité des commits, les nouvelles fonctionnalités du programme.

Très très rarement besoin de faire plus que ça. La synchronisation est importante, deux personnes sur le même bout de code généralement c'est du manque d'organisation, pas quelque chose qui apporte une quelconque valeur. Donc les rebases/merges sont rares

[Frypolar]

C'est vrai mais dans ce cas, autant tout faire avec l'IDE, remontées comprise...

Ah ben oui. Je reconnais volontiers que pour plein de trucs passer par le terminal est plus rapide/pratique. Mais git est tellement mal branlé que c’est un peu le parfait contre-exemple. Les seules fois où je m’en sers en ligne de commande c’est parce que j’ai des macros enregistrées dans mon clavier. Du coup là c’est plus rapide/pratique qu’un IDE Mais c’est genre pour 3 opérations.

- - - Updated - - -

Trunk based development donc une seule branche (master/main)

Avec une équipe bien synchronisée les merges sont extrêmement rares ou triviaux quand ils se produisent. L'historique est extrêmement lisible, et on peut se concentrer sur l'important: la qualité des commits, les nouvelles fonctionnalités du programme.

Mais oui

[Anonyme20240202]

Ah d'ailleurs malpoli que je suis, y'a les vidéos de CppNow 2021 qui sont postées petit à petit, ça se passe ici:

https://pages.jetbrains.com/cppnow2021

Un example de conf intéressante:





- - - Mise à jour - - -

Et je rappelle le channel CppCon qui contient des confs légendaires, vraiment très intéressants et pratiques parfois, beaucoup de sujets sont abordés, même au dela du strict cadre c++:

https://www.youtube.com/channel/UCMl...RUdWX_JbLCukXg

[war-p]

Au cas où : tu sais squasher avec git ? (et good news, les IDE savent enfin le faire)
Ca change la vie, un peu comme le burger au camembert pané
Les worktrees un peu aussi.

Ouais enfin le squash c'est pas terrible quand tu veux garder l'historique, et mis à part pour virer des commit de wip, ça sert à rien surtout avec gitflow.
Sinon une vraie bonne astuce, saviez vous qu'on peut ressusciter des commit squashé justement ou tout simplement perdu dans un rebase infernal ? Il y a moyen de faire un reflog pour récupérer la référence du commit perdu et ensuite il suffit de faire un cherry pick dessus.
Et encore plus fort, savez vous qu'on peut se servir de git sans que les commit s'enchaînent de cette manière ?

[deathdigger]

Je comprends même pas 1/4 de ce que vous dites, suis trop vieux pour ces conneries
Là je suis en train de chercher la meilleure façon de gérer le versioning du code-source (pour pouvoir faire notamment des rollbacks si besoin).
En gros, j'ai un code source que je veux sauver avant de modifier.
J'imagine que je dois passer par des branches, mais je ne sais pas trop si c'est la bonne façon de faire.

Ce que je ferai spontanément, c'est faire une branche à partir du master et considérer que c'est ma version 1.0
Ensuite, je redéveloppe sur le master pour faire ma version 1.1. En gros, la 1.0 serait une branche morte si je n'ai pas besoin de faire de rollback. J'ai bon, ou ce n'est pas la bonne direction ?

[Dross]

Tu devrai plutôt développer tes nouvelles fonctionnalités dans des branches séparées, et merger vers la "master" quand ça part en prod. Tu peux même faire une branche intermédiaire "develop" si tu veux une version de test (à coller dans un CICD par exemple).

Pour les releases, tu as les tags qui te permettent de remonter à une certaine version, souvent c'est largement suffisant.

Si ça ne l'est pas, tu peux partir sur des branches (mortes et de travail) de type : Master => SP01 => Release01. La release est en lecture seule c'est pour l'archivage. La SP c'est au cas où un de tes clients à un problème et que tu ne veux pas lui donner la dernière version, tu travaille dedans et tu remonte si nécessaire les fixs dans la master à la fin. Mais c'est l'artillerie lourde là par contre.

[deathdigger]

C'est un truc que je ne comprends pas. Je peux "naviguer" dans les versions avant mes commit (sur le site, en haut à droite des fichiers), mais comment je fais pour "retourner" à cette étape ?

[Dross]

git checkout <hash-du-commit> de mémoire

[vv221]

Exact, avec la possibilité de n’aller récupérer que certains fichiers donnés plutôt que de basculer complètement sur le commit :

git checkout <hash-du-commit> -- <fichier1> <fichier2>

[Orhin]

C'est vrai mais dans ce cas, autant tout faire avec l'IDE, remontées comprise...

Ah mais je suis d'accord là dessus.

Ouiiiii ^^ mais difftool ne corrige pas les imports, ne détecte pas les erreurs de syntaxe, etc. Le faire en 3 colonnes dans un bon IDE ça a son petit intérêt

Ceci.
Pouvoir avoir des merge propres directement c'est quand même pratique.

Reste que c'est à cause de gens comme vous (en réalité pas vraiment, je sais bien) que nos boss ne veulent pas payer de licences IntejjiJ. Ducon il travaille est heureux sous Vim. Tss...

Ça c'est un truc que j'ai jamais compris de la part de pas mal de boites.
Une licence d'un IDE ça coute généralement entre 200 et 500€, soit le prix d'à peine 2 jours de boulot.
Si tu bosses 218 jours par an, suffit donc que ton IDE améliore ta productivité de 1% pour que ce soit rentable.

Même en s'en foutant totalement du bien être/confort des devs, c'est juste un investissement logique pour une entreprise.

[olih]

Prosus se paie Stack Overflow pour 1,8 milliard de dollars

[Lazyjoe]

Je comprends même pas 1/4 de ce que vous dites, suis trop vieux pour ces conneries
Là je suis en train de chercher la meilleure façon de gérer le versioning du code-source (pour pouvoir faire notamment des rollbacks si besoin).
En gros, j'ai un code source que je veux sauver avant de modifier.
J'imagine que je dois passer par des branches, mais je ne sais pas trop si c'est la bonne façon de faire.

Ce que je ferai spontanément, c'est faire une branche à partir du master et considérer que c'est ma version 1.0
Ensuite, je redéveloppe sur le master pour faire ma version 1.1. En gros, la 1.0 serait une branche morte si je n'ai pas besoin de faire de rollback. J'ai bon, ou ce n'est pas la bonne direction ?

On ne dit plus "master" c'est stigmatisant.

Mais sinon le versioning à la git il faut un peu changer de point de vue. Tu n'as pas un code monolithique avec différentes versions, tu as ton dépôt qui contient le code dans sa globalité, et ce code aura plein d'états différents, et à chaque commit tu vas créer un nouvel état. L'intérêt c'est de pouvoir y mettre tout ce que tu veux (les versions release bien propres, les betas pas encore sûres à 100%, des fonctionnalités expérimentales pétées....) et de facilement y naviguer (tu passes d'un état à un autre facilement, mais c'est beaucoup plus riche que "faire du rollback"), le défaut c'est que tu dois gérer toi-même où tu mets les choses.


En solo il suffit de se cantonner aux recommandations classiques comme dit plus haut :
- la branche master contient le code en état "prod" (ça a été testé, ça compile et ça tourne)
- des branches secondaires pour les évolutions du code qui ajoutent de nouvelles fonctionnalités, modifient la structure fondamentale du code ou ont de gros risques de tout péter

Et à la fin, soit ta branche secondaire est abandonnée et elle reste morte, soit elle arrive à un état satisfaisant pour être intégrée au master et là tu vas faire un merge. Le truc un peu délicat à comprendre c'est que ce genre d'opération ne modifie pas le code en lui-même mais l'état du dépôt.
En faisant le merge tu vas créer un nouvel état où le code contient ce qui a été fait dans le master et dans la branche, la branche en elle-même existe toujours et tu pourras toujours remonter l'historique de ses commits, repartir dans de nouveaux développements indépendants après le merge, etc...

La grosse question dans l'affaire c'est à quelle granularité tu décides de créer une nouvelle branche dans le code... et c'est là que les prises de têtes arrivent quand tu commence à avoir beaucoup de monde qui développe en même temps sur un même dépôt. Certains aiment créer une branche pour le moindre caractère modifié, si tu es seul ou presque à modifier le code c'est pas franchement utile pour ce qui n'a pas ou peu d'impact sur la structure générale du code (bugfixes localisés, docu, fichiers de config pour une nouvelle machine...).

Pour le nommage des versions ça se passe par les tags qui consistent juste à mettre un nom compréhensible sur un commit particulier.

Un exemple de workflow typique :
- tu commence le développement de l'appli de manière linéaire
- moultes commits dans le master (à chaque fois qu'il y a un morceau de plus implémenté qui compile et tourne bien)
- le code atteint un état où tout ce que tu voulais mettre semble fonctionner correctement => tu le taggue "Version 1.0" ou "beta" ou ce que tu veux
- tu as une idée de nouvelle fonctionnalité fabuleuse : tu crée la branche "THIS_IS_NOT_A_FEATURE_THIS_IS_A_REVOLUTION" à partir du commit taggué "Version 1.0" et commence des développements dessus
- entre-temps des utilisateurs t'ont fait remonter 4 bugs
- tu corriges ces bugs dans 4 commits individuels que tu push sur la branche master
- tu te dis que tous ces correctifs méritent d'être mis en avant : tu taggue "Version 1.1" sur le dernier
- tu reprends le développement dans ta branche révolutionnaire mais tu te dis que c'est dommage de ne pas avoir ces nouveaux correctifs de la 1.1
- Et là magie de git, tu as ce qui est une des meilleures features de ce système de versioning : le rebase. Tu vas dire à git : je ne veux plus que la base de ma branche parte du commit "Version 1.0" mais qu'elle parte du commit "Version 1.1". Et voilà, en une commande toute simple tu as mis à jour le code de ta branche avec tout ce qui avait évolué parallèlement dans le master.

[Getz]

Et pour finit tu merge ta branche THIS_IS_NOT_A_FEATURE_THIS_IS_A_REVOLUTION dans master avec un fast forward, et tu as un historique git parfaitement linéaire sans commit de merge

[Lazyjoe]

Et pour finit tu merge ta branche THIS_IS_NOT_A_FEATURE_THIS_IS_A_REVOLUTION dans master avec un fast forward, et tu as un historique git parfaitement linéaire sans commit de merge

Du calme, ça va faire trop d'un coup faudrait pas lui provoquer un AVC.

[Getz]

Du calme, ça va faire trop d'un coup faudrait pas lui provoquer un AVC.

Boh, le plus dur est de passer l'étape du rebase quand même
Après ça, le fast forward c'est trivial.

[Robix66]

Merci pour les infos, chez nous on saute le pas cette semaine.

[Taro]

On ne le dira jamais assez,

git pull

c'est le mal.