Re commentateur-ice ! Chope mes meilleurs infos pour réussir ta carrière de dev : alorsondev.com Si tu penses que cette vidéo est chouette, alors tu vas adorer ce banger A très vite !
Merci beaucoup pour tes vidéos, je n'ai presque aucune expérience en entreprise et grâce à toi, je vois des choses que je n'ai jamais vue en formation. Un grand merci 😃
Je me demande d'où vient cette peur de Git ! La plupart des dévs que j'ai rencontré le fuient comme la peste (de l'étudiant à l'ingé avec 17 ans de carrière). Je fais partie de ceux qui aiment la gestion des conflits. Ça me détend ! Du coup, je suis toujours admin du master. 😂Et puis, c'est grace à ça qu'on se familiarise avec une base de code et qu'on apprend à mesurer l'impact de son travail ainsi que les bonnes pratiques de développement. Bravo pour cette vidéo si bien détaillée !
Haha t'as le goût du challenge dans le sang ! Oui ça a cet avantage-là aussi ! Pour ce qui est de la peur de Git, c'est peut-être parce que d'un côté on ne passe pas beaucoup de temps à l'apprendre, et de l'autre tu sais que si tu fais une connerie (ce qui peut arriver facilement, puisque tu ne maîtrises pas bien l'outil), ça peut avoir de sacrées répercussions Merci Geneviève pour tes félicitations, elles me font chaud au coeur !!
ça doit être à cause de mauvaises expèriences... par exemple moi je me suis fait dégagé car je savais pas les résoudre, même si j'avais jamais de formation git à l'époque, pourtant je suivait toutes les étapes, mais je comprenais pas.. La je fait une vrai formation maintenant et je suis plus serein, je comprends mieux, malgré tout j'appréhende...
Sur VScode tu as onglet Git juste à l'extrémité gauche (ou droite) de ton écran . C'est un outil très intéressant que je conseil de regarder. Tu peux aussi ajouter l'extension Git Graph qui te donne une belle interface graphique de tes branches. Sinon il y a GitKraken (plus robuste, mais sous licence).
@@Alorsondev merci, par contre j'ai essayé de le configurer dans VScode j'ai j'ia pas réussi, j'y est passé la matiné t'as un lien ou une astuce pour l'install ? obs: j'utilise VSC sur W11
Merci pour cette vidéo, tu prends bien le temps et ça fait plaisir ! Comme on dit on apprend plus de quelqu'un qui est quelques années devant nous que d'un spécialiste avec 30 ans de carrière derrière lui, et ta chaîne le démontre parfaitement ! J'ai quelques petites questions de débutant :) - Est-ce que c'est pas nécessaire d'utiliser git pull origin main et git push origin ta-branche (avec aussi remote quelque part) au lieu de juste git pull et git push comme tu le fais ? J'avoue que cet aspect me perd totalement (peut-être une idée de vidéo ? :) - A 36:17 tu fais Ctrl + Shift + R c'est ca ? Est-ce que c'est un raccourci de Github ? Équivalent à cliquer sur 'Resolve conflicts'? - A la fin du conflit, tu merges toi-même la PU, on est d'accord qu'en entreprise ce serait plutôt à quelqu'un d'autre de faire ça genre le lead ou le CTO? - Concrètement est- ce qu'après avoir ouvert un PU on peut passer tout de suite sur une nouvelle tâche ?
Hello ! Merci beaucoup pour ton commentaire, qui a moi aussi me fait très plaisir ! Je suis vraiment contente que mon contenu puisse t'être utile :) - Non, pas besoin de préciser `origin` avec `git pull` - le `origin` est implicite. En revanche, la première fois qu'on push une branche, on tape `git push -u origin nom-de-ta-branche`, pour pouvoir la set en remote (`-u` est le diminutif de `set-upstream`). Pour les push qui suivent, tu peux juste écrire `git push` - Yes Ctrl + Shift + R ! C'est pour réactualiser la page sans tenir compte du cache, pour être sûre de voir des infos à jour. Ca fonctionne pour n'importe quelle page, pas juste Github - Oui, dans une boîte, c'est une autre personne qui merge la PR - c'est généralement un-e collègue dev ;) - Yes on peut !
Par rapport au push -force après un rebase, je pense qu’il est préférable de faire un push -force-with-lease, peut-être pour adoucir le rebase du code… Qu’en penses-tu ?
Excellente idée ! Tu viens de m'apprendre cette option et je t'en remercie chaleureusement 🙏🏾 J'ai déjà écrasé des commits de collègues en faisant un --force classique en plus, donc le with-lease est vraiment bienvenu
Faire des rebase réguliers ne permet en effet pas d'éviter les conflits, mais d'en limiter le scope, car il y a moins de nouveaux changements à intégrer, étant donné que la régularité du rebase (et l'application de cette discipline) permet de travailler en petites itérations successives.
Entre le rebase et le merge, il n'y a pas à choisir. ils ont tous les deux leur utilité. LA question qu'il faut se poser est la suivante. Doit on conserver la branche qu'on a mergée ou rebasée ou pas. SI c'est non alors on rebase si c'est oui alors on merge. Le cas du merge le plus évident est le suivant. on suppose que sur un projet une version 1 est en prod et que les devs bossent sur la version 2. Or on trouve un bug urgent sur la prod. De plus on s'aperçoit que le bug existe aussi sur la version 2. En urgence on corrige le bug sur la version 1 et on relivre la version 1. Mais il va falloir reporter la correction sur la version 2. Là le merge est indispensable car la version 1 va continuer sa vie et potentiellement avoir de nouveaux bugs. Il faut donc bien garder les deux branches. Par contre si la branche ne comporte que des nouveautés et que l'historique des développements n'a pas a être conservé, là c'est le rebase qui s'impose car il simplifie l'historique.
@@Alorsondev bien-sûr après que j’avais réussi à résoudre le conflit cela m’avait permit d’apprendre un plus en dehors la commande favorite que j’avais git add . 😅 Toutes mes félicitations Abi merci pour la motivation 🙏🏾❤️
Sinon, dépendant des projets, vous bossez avec code server (en remote donc) et ce que vous perdez en relative difficulté, vous le gagnez en évitants des conflits. Sinon vous faites de l'écriture inclusive pour client ? Franchement c'est ridicule les parisiens. Si homme : client SI femme : cliente Si non genré (lol) : client. (neutre), merci, bonne année
![[DEV] Comment se passe une formation en reconversion ?](http://i.ytimg.com/vi/ao59Uan86LM/mqdefault.jpg)
Re commentateur-ice !
Chope mes meilleurs infos pour réussir ta carrière de dev : alorsondev.com
Si tu penses que cette vidéo est chouette, alors tu vas adorer ce banger
A très vite !
Super intéressante et complète ta vidéo Abi, je me sentirai beaucoup plus zen (c'est tout de même très relatif ...) en cas de conflit. Bravo !!!
Ah c’est superbe Frédéric !! Merci beaucoup pour ton commentaire ! Des résolutions sereines à toi alors ;)
Merci beaucoup pour tes vidéos, je n'ai presque aucune expérience en entreprise et grâce à toi, je vois des choses que je n'ai jamais vue en formation. Un grand merci 😃
J’en suis ravie Sarah ! L’objectif est rempli alors 😉
Tes transmissions sont riches et didactiques. Top! Merci
Merci beaucoup à toi ☺️
Je me demande d'où vient cette peur de Git ! La plupart des dévs que j'ai rencontré le fuient comme la peste (de l'étudiant à l'ingé avec 17 ans de carrière). Je fais partie de ceux qui aiment la gestion des conflits. Ça me détend ! Du coup, je suis toujours admin du master. 😂Et puis, c'est grace à ça qu'on se familiarise avec une base de code et qu'on apprend à mesurer l'impact de son travail ainsi que les bonnes pratiques de développement. Bravo pour cette vidéo si bien détaillée !
Haha t'as le goût du challenge dans le sang ! Oui ça a cet avantage-là aussi !
Pour ce qui est de la peur de Git, c'est peut-être parce que d'un côté on ne passe pas beaucoup de temps à l'apprendre, et de l'autre tu sais que si tu fais une connerie (ce qui peut arriver facilement, puisque tu ne maîtrises pas bien l'outil), ça peut avoir de sacrées répercussions
Merci Geneviève pour tes félicitations, elles me font chaud au coeur !!
Peut-être la peur d’être celui qui cassera l’application 😂
@@samtoche Je n'aimerais pas être cette personne non plus 😂 Heureusement qu'il y a des process pour éviter de casser le code en production. :)
@@samtoche Héhé tu as tout dit 😁
ça doit être à cause de mauvaises expèriences... par exemple moi je me suis fait dégagé car je savais pas les résoudre, même si j'avais jamais de formation git à l'époque, pourtant je suivait toutes les étapes, mais je comprenais pas..
La je fait une vrai formation maintenant et je suis plus serein, je comprends mieux, malgré tout j'appréhende...
Excellent !
Merci beaucoup ☺
Merci pour la vidéo !
Avec grand plaisir !
Sur VScode tu as onglet Git juste à l'extrémité gauche (ou droite) de ton écran . C'est un outil très intéressant que je conseil de regarder. Tu peux aussi ajouter l'extension Git Graph qui te donne une belle interface graphique de tes branches. Sinon il y a GitKraken (plus robuste, mais sous licence).
Il existe également l’outil mergetool qui permet la resol des conflits avec également 3 vues dont une seule est modifiable
Source Control ? Oui c'est génial, généralement j'add mes fichiers par ce biais ;) et merci pour les extensions !
@@samtoche Génial ! Merci beaucoup
Super vidéo, je me rconnais :D
Au fait tu utilises quoi comme plugin pour l'affichage du chemin en couleur dans le terminal ?
Héhé 😁
J’utilise oh my zsh !
@@Alorsondev merci, par contre j'ai essayé de le configurer dans VScode j'ai j'ia pas réussi, j'y est passé la matiné
t'as un lien ou une astuce pour l'install ?
obs: j'utilise VSC sur W11
Je decouvres la chaine, je m'abonnes, je suis fan ! Merci pour la video !
Oh c'est génial ! Merci beaucoup pour ton soutien :)
Merci pour cette vidéo, tu prends bien le temps et ça fait plaisir ! Comme on dit on apprend plus de quelqu'un qui est quelques années devant nous que d'un spécialiste avec 30 ans de carrière derrière lui, et ta chaîne le démontre parfaitement ! J'ai quelques petites questions de débutant :)
- Est-ce que c'est pas nécessaire d'utiliser git pull origin main et git push origin ta-branche (avec aussi remote quelque part) au lieu de juste git pull et git push comme tu le fais ? J'avoue que cet aspect me perd totalement (peut-être une idée de vidéo ? :)
- A 36:17 tu fais Ctrl + Shift + R c'est ca ? Est-ce que c'est un raccourci de Github ? Équivalent à cliquer sur 'Resolve conflicts'?
- A la fin du conflit, tu merges toi-même la PU, on est d'accord qu'en entreprise ce serait plutôt à quelqu'un d'autre de faire ça genre le lead ou le CTO?
- Concrètement est- ce qu'après avoir ouvert un PU on peut passer tout de suite sur une nouvelle tâche ?
Hello !
Merci beaucoup pour ton commentaire, qui a moi aussi me fait très plaisir ! Je suis vraiment contente que mon contenu puisse t'être utile :)
- Non, pas besoin de préciser `origin` avec `git pull` - le `origin` est implicite.
En revanche, la première fois qu'on push une branche, on tape `git push -u origin nom-de-ta-branche`, pour pouvoir la set en remote (`-u` est le diminutif de `set-upstream`). Pour les push qui suivent, tu peux juste écrire `git push`
- Yes Ctrl + Shift + R ! C'est pour réactualiser la page sans tenir compte du cache, pour être sûre de voir des infos à jour. Ca fonctionne pour n'importe quelle page, pas juste Github
- Oui, dans une boîte, c'est une autre personne qui merge la PR - c'est généralement un-e collègue dev ;)
- Yes on peut !
@@Alorsondev Merci beaucoup pour ta réponse !
Par rapport au push -force après un rebase, je pense qu’il est préférable de faire un push -force-with-lease, peut-être pour adoucir le rebase du code… Qu’en penses-tu ?
Excellente idée ! Tu viens de m'apprendre cette option et je t'en remercie chaleureusement 🙏🏾 J'ai déjà écrasé des commits de collègues en faisant un --force classique en plus, donc le with-lease est vraiment bienvenu
Faire des rebase réguliers ne permet en effet pas d'éviter les conflits, mais d'en limiter le scope, car il y a moins de nouveaux changements à intégrer, étant donné que la régularité du rebase (et l'application de cette discipline) permet de travailler en petites itérations successives.
On est d'accord ;)
Entre le rebase et le merge, il n'y a pas à choisir. ils ont tous les deux leur utilité. LA question qu'il faut se poser est la suivante. Doit on conserver la branche qu'on a mergée ou rebasée ou pas. SI c'est non alors on rebase si c'est oui alors on merge. Le cas du merge le plus évident est le suivant. on suppose que sur un projet une version 1 est en prod et que les devs bossent sur la version 2. Or on trouve un bug urgent sur la prod. De plus on s'aperçoit que le bug existe aussi sur la version 2. En urgence on corrige le bug sur la version 1 et on relivre la version 1. Mais il va falloir reporter la correction sur la version 2. Là le merge est indispensable car la version 1 va continuer sa vie et potentiellement avoir de nouveaux bugs. Il faut donc bien garder les deux branches. Par contre si la branche ne comporte que des nouveautés et que l'historique des développements n'a pas a être conservé, là c'est le rebase qui s'impose car il simplifie l'historique.
❤
J'ai un collègue qui crie tout le temps au bureau à cause de Git 😅
Loooool
J’avais abandonné un projet sur sur ma contribution que j’avais porté sur Github à cause des conflits git que j’avais rencontré. 🤧
Ohhhh 😢j'espère qu'à l'avenir ce ne sera plus un problème 🙏
@@Alorsondev bien-sûr après que j’avais réussi à résoudre le conflit cela m’avait permit d’apprendre un plus en dehors la commande favorite que j’avais git add . 😅
Toutes mes félicitations Abi merci pour la motivation 🙏🏾❤️
@@brx-hashcode Soit on gagne soit on apprend 😉
Merci à toi BRUXX pour tes mots, belle continuation à toi !
@@Alorsondev Merci beaucoup à toi également Abi
vidéo trop longue
Sinon, dépendant des projets, vous bossez avec code server (en remote donc) et ce que vous perdez en relative difficulté, vous le gagnez en évitants des conflits.
Sinon vous faites de l'écriture inclusive pour client ? Franchement c'est ridicule les parisiens.
Si homme : client
SI femme : cliente
Si non genré (lol) : client. (neutre), merci, bonne année