Discussion :

[petitours]

Entièrement d'accord avec abbe2017 !!

En règle générale, avant de commiter / pusher / puller avec GIT, je commence par faire une copie du répertoire. Voire le zipper et le recopier ailleurs ! GIT, c'est pas pour les débutants - et même avec de l'expérience des outils de versioning (SCCS, CVS, SVN...) j'ai toujours du mal à bien comprendre ce que fait GIT - a fortiori quand son fonctionnement est masqué par un IDE...

En espérant que la réponse sera suffisamment simple pour ne pas partir en hors sujet : quel est l’intérêt d'utiliser Git alors ? intérêt qui est peut être très différent d'un développeur à un autre, ne serait ce que de part la taille de l'équipe ?? (il n'y a pas du tout d'ironie dans ma question ; je me la pose vraiment, contraint entre le besoin de faire du versioning et mon incapacité depuis des années à comprendre le fonctionnement des outils en question)

Merci

[LSMetag]

En espérant que la réponse sera suffisamment simple pour ne pas partir en hors sujet : quel est l’intérêt d'utiliser Git alors ? intérêt qui est peut être très différent d'un développeur à un autre, ne serait ce que de part la taille de l'équipe ?? (il n'y a pas du tout d'ironie dans ma question ; je me la pose vraiment, contraint entre le besoin de faire du versioning et mon incapacité depuis des années à comprendre le fonctionnement des outils en question)

Merci

Le but de GIT est d'offrir un versioning décentralisé.
Le principe est qu'au lieu de faire des commit et des get sur un même repository, chacun va cloner l'intégralité du dépôt sur sa machine. Et diviser ensuite chaque tâche en branches distinctes, pour qu'en gros il n'y ait pas de conflits au moment du merge. Ensuite, chacun peut développer dans son coin, en ayant pas ou peu besoin du réseau. Quand on commit, on ne le fait que sur son dépôt local. Il faut faire un "push" manuellement ensuite, et normalement GIT s'occupe de faire un merge correct sur le dépôt distant.

Donc ça permet de soulager le réseau, de bien segmenter les morceaux de l'appli, surtout pour les grosses équipes, et aussi de faire des forks.

[LSMetag]

Je viens de me poser une question :

Comment a-t-il fait pour tout perdre ? Son dépôt local et son dépôt global ? Il n'aurait pas fait un clone d'un dépôt vide sur son dossier de solution non versionnée par hasard ?

[Yogui]

Plusieurs milliers+ de fichiers en quelques mois, c'est toujours jouable avec certains frameworks, surtout en archivant ledit FW et son cache/tmp dans l'outil SCM

[petitours]

Le but de GIT est d'offrir un versioning décentralisé.
Le principe est qu'au lieu de faire des commit et des get sur un même repository, chacun va cloner l'intégralité du dépôt sur sa machine. Et diviser ensuite chaque tâche en branches distinctes, pour qu'en gros il n'y ait pas de conflits au moment du merge. Ensuite, chacun peut développer dans son coin, en ayant pas ou peu besoin du réseau. Quand on commit, on ne le fait que sur son dépôt local. Il faut faire un "push" manuellement ensuite, et normalement GIT s'occupe de faire un merge correct sur le dépôt distant.

Donc ça permet de soulager le réseau, de bien segmenter les morceaux de l'appli, surtout pour les grosses équipes, et aussi de faire des forks.

Merci, ça m'a redonné motivation pour me replonger dans ce dur monde du versioning. Je suis à l'age de pierre sur ce sujet
ou un boulet qui n'a jamais réussi a y comprendre quelquechose ?
ou un vieux .on froussard qui sais pas profiter des outils modernes
à moins que ce soit de la faute du stagiaire...

[Lolo78]

Essayez, que ce soit en ligne de commande ou au clic, de créer 5 millions de fichiers même sans rien y mettre dedans, c'est impossible en 3 mois.

Bah, j'ai mis moins d'une minute pour écrire ce script à la ligne de commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 perl -e 'for my $i (1..10) { open my $OUT, ">", "test$i.txt"; print $OUT $i; close $OUT; } '

Résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test2.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test1.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test8.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test7.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test6.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test5.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test4.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test3.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test9.txt
-rw-r--r--  1 Laurent         None             2 23 août  20:55 test10.txt

J'ai volontairement limité le nombre de fichiers à 10, mais il suffit de remplacer 10 par 5000000 dans le script, et j'aurai mes cinq millions de fichiers en quelques minutes (sauf si le file system rend l'âme, bien sûr, je vais donc éviter d'essayer). Et je mets même quelque chose de différent dans chacun de mes fichiers.

[Lolo78]

Et puis bien sûr, autre petit détail, le post d'origine parle de cinq milliers de fichiers, pas de cinq millions.

[TJ1985]

Il est bien énervé, le jeunet. Il n'y a simplement aucune excuse à lui trouver. Trois mois de boulot ça fait du volume. S'il n'a pas été foutu de mettre en place un backup local voire une simple copie locale durant ce temps, tant pis pour lui. Et si il n'a même pas l'élémentaire intelligence de faire un jeu de test quand il essaie un nouveau soft, il a meilleur temps de changer de métier.
On peut éventuellement reprocher à l'informatique actuelle d'avoir trop simplifié les environnements et d'avoir trop complexifié les langages. Mais il faut faire avec et accepter de réfléchir un minimum à ce qu'on fait, toujours.

[TJ1985]

Merci, ça m'a redonné motivation pour me replonger dans ce dur monde du versioning. Je suis à l'age de pierre sur ce sujet
ou un boulet qui n'a jamais réussi a y comprendre quelquechose ?
ou un vieux .on froussard qui sais pas profiter des outils modernes
à moins que ce soit de la faute du stagiaire...

Vas-y tranquillement, ça vaut vraiment la peine de consacrer quelques heures pour bien maîtriser le sujet. Git est remarquable d'efficacité et de simplicité. J'ai passé avant par CMS, Visual Source Safe et un prédécesseur de Git dont le nom m'échappe. Je n'ai jamais pu envisager un développement sans contrôle de source, c'est une aide inappréciable qui te décharge completement de toute une partie administrative dont on n'a finalement que faire. N'hésite pas si tu as un peu de matos à te faire ton propre serveur, au moins pour jouer. C'est vraiment simple quand on y va tranquillement. Au début j'ai buté sur la séquence commit-push, qui ne m'était pas familière, mais @petitours t'a parfaitement expliqué le truc.

[petitours]

On peut éventuellement reprocher à l'informatique actuelle d'avoir trop simplifié les environnements et d'avoir trop complexifié les langages.

C'est marrant j'aurais dit l'inverse.
Avant un environnement très simple et code compliqué : Quelques fichiers bien ordonnés dans lesquels on sait exactement ce qu'on fait et où se trouve le code mais des langages super complexes où il faut tout gérer (mémoire déjà...).
Maintenant des environnements usine à gaz avec des SDK, des framework, des librairies, des patchs en veux tu en voila avec des soucis de mise à jour et de compatibilité permanents mais avec des langages ultra puissants qui rendent la programmation ultra simple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
using patchDeLaMortQuiTueVersion1.3.4.5.22.42revision45 ;
#include AnalyseToutVersion0.4343Patch ;

ErrorConfigurationDeMonEDIQuiChercheDesTrucsDePartout = CalculTrajectoireDeLaLuneEtAfficheBien();
'Fin du programme

Le Meilleur exemple que j'ai vu récemment c'est AndroidStudio : un "truc" fait pour programmer surement très simplement mais qui a demandé 5jours d'installation (et mises à jour) et lance sur ma machine 10 minutes de compilation sur l'exemple fourni "HelloWord" à chaque fois que je touche le moindre bouton même s'il n'y a pas eu de modifications. Et le pire c'est que les développeurs Android trouvent ça normal !

[petitours]

qui te décharge complètement de toute une partie administrative dont on n'a finalement que faire.

Outre le fait que cette partie administrative est peu intéressante elle est très chronophage et toujours mal faites, même quand on tente d'être rigoureux.
Là je débute sous Linux, je suis proWindows depuis plus de 20 ans mais les orientations de Windows depuis quelques années m'ont décidé en début d'année à abandonner MS sous 2 ans.
J'ai commencé par abandonner Word, suis passé avec bonheur à Latex, maintenant j'attaque en parallèle GNU/Linux et Python (pour remplacer C#) et ça va me bouffer 300% de ma capacité d'apprentissage encore un bon moment !
ensuite je regarde Git, promis ! (en tous cas j'en ai très envie car c'est juste indispensable pour bien bosser, ce que je ne fais pas aujourd'hui du coup )

[TJ1985]

C'est marrant j'aurais dit l'inverse.
Avant un environnement très simple et code compliqué : Quelques fichiers bien ordonnés dans lesquels on sait exactement ce qu'on fait et où se trouve le code mais des langages super complexes où il faut tout gérer (mémoire déjà...).
Maintenant des environnements usine à gaz avec des SDK, des framework, des librairies, des patchs en veux tu en voila avec des soucis de mise à jour et de compatibilité permanents mais avec des langages ultra puissants qui rendent la programmation ultra simple.

J'ai bossé sous VMS pendant une quinzaine d'années, puis en mélange Windows + VMS une dizaine. Sous VMS j'ai co-écrit un environnement de développement en DCL, le langage de scripting de VMS, en m'appuyant sur CMS (gestion de sources) et MMS (gestionnaire de build). Ca a fait mal aux pattes, à la tête un peu aussi, mais ce truc fonctionne depuis 25 ans et a pu suivre sans soucis les évolutions d'architecture initiées par DEC puis les repreneurs de VMS. On gérait avec lui des centaines de milliers de fichiers, des centaines d'applications, plus ou moins complexes, le travail coopératif, etc. Mais même après tout ce temps, la plupart des développeurs utilisaient mal les fonctions de gestion de version, pourtant simplissimes.
A contrario, j'ai utilisé des langages spécialisés comme ACMS, DECForms, DCL, SQL etc et COBOL et Pascal comme langages universels. A mon point de vue ils sont verbeux, puisqu'on doit tout leur dire, mais ils sont simples. Tu gères tout, effectivement, et en Pascal tu n'as pas forcément besoin de trop faire attention à la mémoire. Aujourd'hui je me suis mis à Swift et au développement Xcode... Le moins qu'on puisse dire c'est qu'à force de vouloir simplifier les choses les plus simples, c'est devenu fort compliqué ! Tu sais quand utiliser un Optionnal, toi ? Moi, j'hésite encore !

[Marco46]

Le but de GIT est d'offrir un versioning décentralisé.
Le principe est qu'au lieu de faire des commit et des get sur un même repository, chacun va cloner l'intégralité du dépôt sur sa machine. Et diviser ensuite chaque tâche en branches distinctes, pour qu'en gros il n'y ait pas de conflits au moment du merge. Ensuite, chacun peut développer dans son coin, en ayant pas ou peu besoin du réseau. Quand on commit, on ne le fait que sur son dépôt local. Il faut faire un "push" manuellement ensuite, et normalement GIT s'occupe de faire un merge correct sur le dépôt distant.

Donc ça permet de soulager le réseau, de bien segmenter les morceaux de l'appli, surtout pour les grosses équipes, et aussi de faire des forks.

Vala.

La gestion des branches il y a plusieurs stratégies possibles. Les conflits au moment des merge ça dépend des stratégies et de leur compréhension et mise en oeuvre par les devs.

GIT ne fait pas que gérer le versioning, il permet également de gérer les déploiements ce qui est absolument formidable. GIT étant décentralisé, il sait communiquer via plusieurs protocoles d'un repo git à un autre. D'où l'usage massif par les devops.

Dans les grandes différences fondamentales il y a le fait que les commits étant créés en local, ils restent privés tant que le développeur n'a pas choisi de les publier. Cela crée une différence gigantesque sur ce qu'est l'historique d'un code source géré avec un VCS centralisé et un VCS décentralisé. Dans un VCS centralisé, l'historique des commits est plus proche d'un log des actions des développeurs, alors que dans un VCS décentralisé, comme les développeurs choisissent quand ils publient ils peuvent remodeler leurs commits avant de publier pour leur donner du sens, et du coup l'historique des commits à réellement du sens, ce n'est plus un simple log idiot.

C'est une notion fondamentale qui a de très nombreuses implications et c'est souvent ça qui est mal compris par les gens qui viennent de SVN.

Si vous avez des questions sur git je serai ravi d'y répondre dans la section git du forum qui est je trouve étonnamment assez peu active.

[alexf007]

Il y a une erreur de traduction, il parle de 5 thousand files.. soit 5 mille fichiers, pas 5 millions ;-)

c'est plutôt une erreur de lecture non ? c'est clairement écrit 5 milliers de fichiers, pas 5 millions.

[Jipété]

c'est plutôt une erreur de lecture non ? c'est clairement écrit 5 milliers de fichiers, pas 5 millions.

Non : l'auteur du post d'origine s'est rendu compte de son erreur et a édité son message.

Car ils sont nombreux à avoir relevé "5 millions" : celui que tu cites, plus

Ça ressemble quand même à un gros troll.
3 mois (selon les manifestants), on peut donc supposer que ça tourne plutôt de l'ordre de 3 semaines/1mois (selon la police )

5 millions de fichiers, on peut dire probablement quelques centaines. Allez, en 1 mois, s'il est productif, on lui accorde le millier.

Et on ne le dit jamais (et nous même la plupart du temps ne le faisons pas), avant toute chose, avant de commencer quoique ce soit : RTFM

et

C'est du fake ça, c'est pas possible autrement.

- Trois mois de travail
- 5 millions de fichiers

Essayez, que ce soit en ligne de commande ou au clic, de créer 5 millions de fichiers même sans rien y mettre dedans, c'est impossible en 3 mois.

- 0 connaissance concernant git
- 0 connaissance concernant les systèmes de backup (bien que dans ce cas apparemment il n'y a pas de faille matériel)
- 0 connaissance.. tout simplement

Mais trois mois de travail et 5 millions de fichiers, et surtout sous Windows.. un vrai pro !

Et je n'ai pas tout relu.

[Asmodan]

[MKuser53]

[LSMetag]

Vala.

La gestion des branches il y a plusieurs stratégies possibles. Les conflits au moment des merge ça dépend des stratégies et de leur compréhension et mise en oeuvre par les devs.

GIT ne fait pas que gérer le versioning, il permet également de gérer les déploiements ce qui est absolument formidable. GIT étant décentralisé, il sait communiquer via plusieurs protocoles d'un repo git à un autre. D'où l'usage massif par les devops.

Dans les grandes différences fondamentales il y a le fait que les commits étant créés en local, ils restent privés tant que le développeur n'a pas choisi de les publier. Cela crée une différence gigantesque sur ce qu'est l'historique d'un code source géré avec un VCS centralisé et un VCS décentralisé. Dans un VCS centralisé, l'historique des commits est plus proche d'un log des actions des développeurs, alors que dans un VCS décentralisé, comme les développeurs choisissent quand ils publient ils peuvent remodeler leurs commits avant de publier pour leur donner du sens, et du coup l'historique des commits à réellement du sens, ce n'est plus un simple log idiot.

C'est une notion fondamentale qui a de très nombreuses implications et c'est souvent ça qui est mal compris par les gens qui viennent de SVN.

Si vous avez des questions sur git je serai ravi d'y répondre dans la section git du forum qui est je trouve étonnamment assez peu active.

Merci pour les précisions. Je suis relativement débutant en Git moi aussi, vu qu'au boulôt c'est uniquement TFS. Git c'est pour le perso.

[gadj0dil0]

Personnellement j'ai lu 5 milliers de fichiers...
Je suis mauvais en boucles mais j'imagine qu'une commande du style echo random_expression > fichier.timestamp dans une boucle va te générer des millions de fichiers très vite au point de dépasser les capacités du système de fichier.

D'ailleurs j'ai eu connaissance au travail du cas où un utilisateur a rendu son système (Debian 7 ou 6) zombie en lançant un code de calcul scientifique qui lui a généré plus de 16 millions de fichiers. Je n'ai pas plus d'infos. Du coup le système ne pouvait plus trouver d'entrée pour les fichiers. Je pense que pour tout système de fichiers il doit y avoir un nombre max de fichiers possibles.

[Artemus24]

Salut à tous.

règle n°1 du développeur :
des sauvegardes perso en local tu feras même si on te dit que c'est fait en ligne (ou cloud) automatiquement le soir.

Tout à fait exacte, sinon c'est travailler sans filet. Il y a des gens qui aiment vivre dangereusement.

En règle n°2, tu maîtriseras le logiciel que tu utilises !

En règle n°3, tu ne viendras jamais bidouiller dans l'environnement de production. L'environnement de test est fait pour cela !

En règle n°4, tu n'accuseras pas les autres d'être responsable de tes bêtises.

En règle n°5, si tu ne sais pas travailler correctement, change de métier !

Une erreur est vite arrivée, même en faisant attention, suffit d'un mauvais jour, mauvais moment et de ne pas être à 100% lol.

Tout le monde peut faire une mauvaise manipulation. Ce sont des choses qui arrivent.
Ce qui est grave, c'est de ne pas prévoir justement une solution de récupération, comme par exemple une sauvegarde quotidienne.
Ou encore bidouiller dans l'environnement de production !!!

C'est du fake ça, c'est pas possible autrement.

Non, non, c'est la trise réalité. Des imbéciles comme ça, c'est beaucoup plus courant qu'on ne le croit.
Sauf que, en général, ils ne viennent pas se vanter sur le net.

En plus 3 mois sans aucun commit, bravo !

Un "commit", c'est pas une sauvegarde mais une validation.

Est-ce qu'il sait ce que signifie le mot "discard" ?

Il ne dois pas comprendre, non plus, l'anglais !

Est-ce un chef ? Ne me dites pas que c'est un chef, voyons.
Pour faire ce genre de connerie et ne pas être viré, c'est nécessairement un chef.
Et les chefs sont capable de tout, d'ailleurs c'est à cela qu'on les reconnaient.

Et on ne le dit jamais (et nous même la plupart du temps ne le faisons pas), avant toute chose, avant de commencer quoique ce soit : RTFM

Quoi donc, le petit livre rouge de Mao Tsé-Toung :

remarquez c'est la même chose ailleurs, on construit une digue après une violente inondation pas avant.

Qui aurait eu l'idée de construire une digue, là où il n'y a pas eu d'inondation avant ?
On réagit souvent quand il est trop tard !

@+