C'est assez simple dans la pratique, mettons que tu bosses sur une branche B (ta branche) et que tu veux merger tes modifs dans une branche A (une branche de release par exemple), d'abords tu récup les modifs de la branche A en mergeant de A vers B, si jamais il y a conflits, git va créer un commit de merge qui est un commit "de conflit". Tu résouds à la main les conflits ( >>>>HEAD, etc), puis tu push, ce qui merge de A vers B. Ensuite, ta branche B est synchro avec la branche A, normalement la branche A est protégée tu peux pas merge direct dedans, à moins que le lead dev fasse de la merde. Du coup tu créés ce qu'on appelle une merge request, pour merger B dans A. Si t'as bien fait ton taff le mec en review de ton code clique sur ok et il n'y a pas de conflits. L'idée pour ne pas être emmerdé outre mesure est de régulièrement merger la branche A dans B tant que tu as des trucs à dev sur ta branche B pour intégrer petit à petit les modifs et éviter de te retrouver avec un giga conflit à la fin. Une fois que tu as merge dans la release en théorie tu supprimes la branche B.
Salut ! Je viens de tomber sur ton compte et ta vidéo. J'aime beaucoup ta façon de présenter, très calme et très clair. En tant qu'apprenant ça met un peu la pression de se dire qu'il faut avoir un niveau entreprise pour git. Mais très heureux de le savoir et de pouvoir anticiper ce travail d'apprentissage. Donc je suis pour un tuto sur la gestion des conflits car je fais encore parti de ceux qui transpirent devant un conflit 😅. Merci encore pour tes conseils ! ;)
Please une vidéo sur les cas pratiques, avec ton terminal, où tu nous montres concrètement comment on casse/délite/fusione des branches dans tous les sens ❤ Merci en tout cas pour ton partage ça fait plaisir de découvrir quelqu'un qui a de la bouteille ;)
Il est important de montrer le principe de "Git flow". C'est une norme qui permet d'identifier les branches sur lesquelles on travaille. Respecter Git flow permet de savoir facilement où en est l'avancement d'un projet (une branche de développement = une tâche, une branche de version= une recette), et d'éviter beaucoup d'erreurs de fusion. En tant que lead, je n'ai pas peur de supprimer les branches de développement ou de version dont les fonctionnalités ont été intégrées en production.
Tout à fait d'accord, merci pour ce résumé. Comment faire justement pour s'exercer par la pratique à git/github quand on débute seul dans le développement? Des fois j'imagine créer deux comptes github et simuler deux codeurs sur un même projet pour faire des manip' comme en entreprise...
Le boss de git c’est Homer Simpson, il gère les conflits de Marge, comme personne 😅 PS: Videv il fait le jeune comme ça, mais il est grillé, il connaît les piles et la gameboy.. c’est un ancien 😂
J’ai une question plus générale dans l’entreprise. Je vais commencer une mission en période d’essais, et je ne connais pas trop les postes de tout le monde, je suis rattaché à mon lead dev, et il y a deja 3 Frontends, et une équipe backend de 4 personnes, un designer. Mais j’aimerai bien reconnaître qui est à mon niveau, qui est mon supérieure, est-ce que je dois faire ce que me demande tout les autres ou uniquement mon lead dev? Merci d’avance.
Salut Videv ! En tant que ton ancien élève de formation, Pourquoi ici la : 0:20 Pour parler d’un mec qui comprend rien au code? Pourquoi tu as choisi un mec qui me ressemblait !? 😒 tu veux me faire passer un message c’est ça ? 😅😂🤣
Je ne suis pas d’accord avec le « tu n’as pas le temps d’apprendre ça et l’entreprise ne va pas le faire elle est pas là pour ça » Pour moi si, si l’entreprise n’accepte pas que tu ne saches pas des choses et ne veut pas t’accompagner dans la formation de transmettre des compétences c’est que c’est pas une bonne entreprise ni une bonne mentalité, en dev on apprend tout le temps, ça demande un tas de compétences différentes, on ne peut pas tout connaître encore moins pour quelqu’un qui débute et pour qui ça serait le premier job en entreprise, s’il se fait viré pour ça, c’est lui qui gagne au change selon moi, c’est bête de la part de l’entreprise de viré une personne juste car elle maîtrise moins une compétence plutôt que de l’aide à l’acquérir Aussi si je peux me permettre un retour constructif sur la vidéo, il est confus de savoir à quel niveau de dev tu t’adresses, au début c’est débutant et puis plus tard, « si l’entreprise vous embauche en tant que confirmé » si tu es confirmé, tu as déjà plusieurs années d’expérience et donc n’est pas censé avoir ces problèmes là sur des situations récurrentes, il y a donc erreur de casting soit de la part de l’entreprise soit de la part du dev. Tu insistes beaucoup sur des dates de livrables, si c’est manqué à cause d’un problème Git c’est que le problème est autre part selon moi. Tu fais des jauges avec tes mains sur les niveaux de git et cite 3 commandes basique mais tu ne dis pas celles qui sont utilisé en entreprise ou la réel différence entre les 2, ça aurait plus claire de détaillé, par exemple expliqué que l’on fait des pull request, qu’il y a des code review, le nommage de commit, de bien ordonné ses commit en ne mettant que des choses cohérentes qui vont ensemble pour faciliter la relecture ou éventuel rollback, qui sont des choses tout aussi importantes que d’avoir gérer la notion de branches , et aussi la notion de rebase pour avoir un bel historique et qui permet d’éviter des conflits
Salut Stitax, je crois que cette vidéo c’est plutôt « ce qu’un lead dev attend de toi » et non « apprend git en … » pour ma part, j’avais fais la formation de Vi, c’est vrai qu’il généralise sur cette vidéo mais je crois que la vidéo est adressée à un débutant qui pense que git add commit push et pull suffisent pour bosser en équipe. À la base je viens de Openclassrooms et on te fais beaucoup croire que ça suffit pour avancer alors que tu vas te ramasser 1000 refus en entretients d’embauche.. malgré vos qualités certaines .. (tu as du connaître ça aussi..) Si tu as déjà ton expérience de dev, tu vas voir le côté lead relou qui est pas flexible .. et tu as 100% raison et vi n’est pas comme ça du tout en formation. Par contre, si tu reviens au toi de tes début et que tu vois cette vidéo, tu serais peut-être heureux que quelqu’un te dises ! Attention c’est bien le git de la maison mais il faut aller plus loin 😊 Dernière chose, en tant que développeur expérimenté que tu es (ça ce sent) tu dois savoir qu’il y a pleins de dev lead très toxic dans le métier, et c’est une bonne chose que vi prépare les dev à ça car c’est la réalité. Il va pas faire croire aux gens que dev c’est Bali et les palmiers h24 comme pas mal de formateur en ligne 😊
Le peuple exige une vidéo sur le merge conflict !
C’est facile : tu n’acceptes que ton code et rejettes celui des autres car tu as t.o.u.j.o.u.r.s raison 😂.
@@tetuaoro mdr😂😂
@@tetuaoro haha 😅
@@tetuaoroOu alors tu crées deux nouvelles branches et test laquelle est la mieux ?
C'est assez simple dans la pratique, mettons que tu bosses sur une branche B (ta branche) et que tu veux merger tes modifs dans une branche A (une branche de release par exemple), d'abords tu récup les modifs de la branche A en mergeant de A vers B, si jamais il y a conflits, git va créer un commit de merge qui est un commit "de conflit". Tu résouds à la main les conflits ( >>>>HEAD, etc), puis tu push, ce qui merge de A vers B. Ensuite, ta branche B est synchro avec la branche A, normalement la branche A est protégée tu peux pas merge direct dedans, à moins que le lead dev fasse de la merde. Du coup tu créés ce qu'on appelle une merge request, pour merger B dans A. Si t'as bien fait ton taff le mec en review de ton code clique sur ok et il n'y a pas de conflits. L'idée pour ne pas être emmerdé outre mesure est de régulièrement merger la branche A dans B tant que tu as des trucs à dev sur ta branche B pour intégrer petit à petit les modifs et éviter de te retrouver avec un giga conflit à la fin. Une fois que tu as merge dans la release en théorie tu supprimes la branche B.
C'est tellement bien illustré et avec un peu d'humour, c'est bien fait.
Tellement de calme et de sérénité dans cette vidéo 😌
Félicitations, possible de faire aussi la pratique en introduisant le fork, upstream... 😂, Depuis la RDCongo
Salut ! Je viens de tomber sur ton compte et ta vidéo. J'aime beaucoup ta façon de présenter, très calme et très clair. En tant qu'apprenant ça met un peu la pression de se dire qu'il faut avoir un niveau entreprise pour git. Mais très heureux de le savoir et de pouvoir anticiper ce travail d'apprentissage. Donc je suis pour un tuto sur la gestion des conflits car je fais encore parti de ceux qui transpirent devant un conflit 😅. Merci encore pour tes conseils ! ;)
Je découvre tes vidéos et c’est très quali : court et bien expliqué. Merci !
Des fondamentaux qu'il est toujours bon de rappeler. Merci Vi !
Please une vidéo sur les cas pratiques, avec ton terminal, où tu nous montres concrètement comment on casse/délite/fusione des branches dans tous les sens ❤
Merci en tout cas pour ton partage ça fait plaisir de découvrir quelqu'un qui a de la bouteille ;)
Mais oui ça serait top ! J’espère qu’il va t’écouter 😋
Merci pour cette vidéo
Merci pour ton commentaire 🦚
Il est important de montrer le principe de "Git flow". C'est une norme qui permet d'identifier les branches sur lesquelles on travaille.
Respecter Git flow permet de savoir facilement où en est l'avancement d'un projet (une branche de développement = une tâche, une branche de version= une recette), et d'éviter beaucoup d'erreurs de fusion.
En tant que lead, je n'ai pas peur de supprimer les branches de développement ou de version dont les fonctionnalités ont été intégrées en production.
Une vidéo sur le Merge conflict please
Merci pour cette vidéo Vi ! Au top comme d’hab 👌🏼 Une vidéo sur les merges conflicts pourrait intéresser bcp de monde je pense ;)
Je suis aussi intéressé par une vidéo sur les merge conflicts.
tu aurait une raod map des commande a absolument savoir ?
Une vidéo sur les merge conflict stp
oui ça m'intéresse un détail sur les merge conflicts !
Hello ! J’aimerai bien une vidéo sur le merge conflit
Super vidéo, que penses tu des git push -f imposés en entreprise sur les branches ? Un client m'a choqué avec ca.
Merci de réaliser une vidéo sur les conflits de merge.
Video sur les conflits svp
On veut une playlist complète sur giiiiitttt 😂😅. Stp bien sûr
Je note ✍
Une vidéo sur les merge conflict !!!
Merge conflict ✋🏽.
Merci pour cette vidéo.
Une video sur merge stp
Bonjour, vive le merge conflict !!!
Explications claires, merci
Always supporting you bro
Je veux que vous faites un cours sur le git en entreprise
👀✍
Comment apprendre Git pour un débutant
Tout à fait d'accord, merci pour ce résumé.
Comment faire justement pour s'exercer par la pratique à git/github quand on débute seul dans le développement? Des fois j'imagine créer deux comptes github et simuler deux codeurs sur un même projet pour faire des manip' comme en entreprise...
T'attrape un ami codeur sinon.
Est ce qu’on utilise git en cmd uniquement ? Ou alors on utilise des gui clients ?
Je suis partant pour la vidéo,vi je voit que tu fait de la guitar moi je fait du piano classique
Comment appelle-t-on un cuisinier qui connaît git ?
Un commit de cuisine 😏
Pas mal mdrrr
Le boss de git c’est Homer Simpson, il gère les conflits de Marge, comme personne 😅
PS: Videv il fait le jeune comme ça, mais il est grillé, il connaît les piles et la gameboy.. c’est un ancien 😂
J’ai une question plus générale dans l’entreprise. Je vais commencer une mission en période d’essais, et je ne connais pas trop les postes de tout le monde, je suis rattaché à mon lead dev, et il y a deja 3 Frontends, et une équipe backend de 4 personnes, un designer. Mais j’aimerai bien reconnaître qui est à mon niveau, qui est mon supérieure, est-ce que je dois faire ce que me demande tout les autres ou uniquement mon lead dev? Merci d’avance.
Une vidéo sur les merles confits
merci
Vidéo sur les merges conflt.
Je sur team plus pull request
une vidéo sur merge conflict 🙏
REVOLUTION - Le peuple exige le merge conflict ! Tu nous hype pour rien :DDD
merge conflict🎉
Merge conflict !
C est quand tu dois unmerge ta branch sous pression que ca devient marrant 🤣
Salut Videv ! En tant que ton ancien élève de formation,
Pourquoi ici la :
0:20
Pour parler d’un mec qui comprend rien au code? Pourquoi tu as choisi un mec qui me ressemblait !? 😒 tu veux me faire passer un message c’est ça ? 😅😂🤣
Moi les commandes de git je gère … je les aies déjà apprises dans ta formation hahahhaha 🤭
J’espère que tu les confonds pas avec tes commandes UberEats
😂😂 bas c’est ça le git de la maison !
merge conflit
Ouais merde conflits nous en avons besoin
Mdr tu as fais exprès d’écrire « merde »conflits ? 😅
Je ne suis pas d’accord avec le « tu n’as pas le temps d’apprendre ça et l’entreprise ne va pas le faire elle est pas là pour ça »
Pour moi si, si l’entreprise n’accepte pas que tu ne saches pas des choses et ne veut pas t’accompagner dans la formation de transmettre des compétences c’est que c’est pas une bonne entreprise ni une bonne mentalité, en dev on apprend tout le temps, ça demande un tas de compétences différentes, on ne peut pas tout connaître encore moins pour quelqu’un qui débute et pour qui ça serait le premier job en entreprise, s’il se fait viré pour ça, c’est lui qui gagne au change selon moi, c’est bête de la part de l’entreprise de viré une personne juste car elle maîtrise moins une compétence plutôt que de l’aide à l’acquérir
Aussi si je peux me permettre un retour constructif sur la vidéo, il est confus de savoir à quel niveau de dev tu t’adresses, au début c’est débutant et puis plus tard, « si l’entreprise vous embauche en tant que confirmé » si tu es confirmé, tu as déjà plusieurs années d’expérience et donc n’est pas censé avoir ces problèmes là sur des situations récurrentes, il y a donc erreur de casting soit de la part de l’entreprise soit de la part du dev.
Tu insistes beaucoup sur des dates de livrables, si c’est manqué à cause d’un problème Git c’est que le problème est autre part selon moi.
Tu fais des jauges avec tes mains sur les niveaux de git et cite 3 commandes basique mais tu ne dis pas celles qui sont utilisé en entreprise ou la réel différence entre les 2, ça aurait plus claire de détaillé, par exemple expliqué que l’on fait des pull request, qu’il y a des code review, le nommage de commit, de bien ordonné ses commit en ne mettant que des choses cohérentes qui vont ensemble pour faciliter la relecture ou éventuel rollback, qui sont des choses tout aussi importantes que d’avoir gérer la notion de branches , et aussi la notion de rebase pour avoir un bel historique et qui permet d’éviter des conflits
Salut Stitax, je crois que cette vidéo c’est plutôt « ce qu’un lead dev attend de toi » et non « apprend git en … » pour ma part, j’avais fais la formation de Vi, c’est vrai qu’il généralise sur cette vidéo mais je crois que la vidéo est adressée à un débutant qui pense que git add commit push et pull suffisent pour bosser en équipe. À la base je viens de Openclassrooms et on te fais beaucoup croire que ça suffit pour avancer alors que tu vas te ramasser 1000 refus en entretients d’embauche.. malgré vos qualités certaines .. (tu as du connaître ça aussi..)
Si tu as déjà ton expérience de dev, tu vas voir le côté lead relou qui est pas flexible .. et tu as 100% raison et vi n’est pas comme ça du tout en formation.
Par contre, si tu reviens au toi de tes début et que tu vois cette vidéo, tu serais peut-être heureux que quelqu’un te dises ! Attention c’est bien le git de la maison mais il faut aller plus loin 😊
Dernière chose, en tant que développeur expérimenté que tu es (ça ce sent) tu dois savoir qu’il y a pleins de dev lead très toxic dans le métier, et c’est une bonne chose que vi prépare les dev à ça car c’est la réalité. Il va pas faire croire aux gens que dev c’est Bali et les palmiers h24 comme pas mal de formateur en ligne 😊
Des développeurs viré car il ne maitrise pas parfaitement git ? T'abuse un peu mdr.
Bonjour, saurais tu ou je pourrais apprendre git ? Merci à toi
@@ninko9117bonjour regard xavki
fait sur une video sur le sujet, @mergeConflit
merci