+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    3 283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 3 283
    Points : 75 945
    Points
    75 945

    Par défaut Microsoft fait le point sur ses contributions dans les performances de Git en 2017

    90 % de l'équipe d'ingénieurs dédiés au développement de Windows a déjà migré vers Git,
    en l'espace de trois mois

    En février, Microsoft a annoncé que son équipe de développement de Windows allait passer à l'utilisation du système de contrôle de version open source Git notamment en raison de Git Virtual File System (GVFS). Brian Harry, Vice President for Cloud Developer Services chez Microsoft, a expliqué que « GVFS, couplé à un ensemble d'améliorations à Git, permet à Git d’échelonner de TRÈS gros dépôts en virtualisant le dossier .git et le répertoire de travail. Plutôt que de télécharger l'intégralité du dépôt et de cocher tous les fichiers, il se limite à télécharger de manière dynamique les portions dont vous avez besoin en fonction de ce que vous utilisez. »

    Trois mois plus tard, Microsoft a publié un billet par l’entremise de Brian Harry où l’entreprise fait le point.

    Avant tout, il a rappelé que la base de code Windows comporte environ 3,5 millions de fichiers et, lorsqu'elle est enregistrée dans un compte Git, cet ensemble donne lieu à un dépôt de 300 Go. En outre, l'équipe de Windows compte environ 4000 ingénieurs et le système d'ingénierie produit 1760 « compilations de laboratoire » quotidiennes sur 440 branches en plus de milliers de compilations de validation de pull request.

    Le passage à Git a été influencé par un certain nombre de choses. En 2013, la société a entrepris son projet OneCore, unifiant ses différents domaines du développement de Windows et faisant en sorte que le système d'exploitation soit une plateforme en couches plus modulaire. À l'époque, Microsoft utilisait Source Depot, une version personnalisée du système de contrôle de la version Perforce commercial, pour tous ses projets majeurs.

    Source Depot n'a pas pu gérer un projet de la taille de Windows, donc, au lieu d'avoir l'ensemble du système d'exploitation dans un seul dépôt, le code Windows a été divisé en des dizaines de référentiels, avec une sorte de couche de virtualisation en tête pour produire une vue unifiée de tout le code. Parmi ces dépôts figuraient des composants isolés, autonomes, d’autres ont été développés verticalement ou horizontalement à travers le système d'exploitation. En définitive, en tant que telle, la structure ne correspondait pas au module OneCore.

    « Toutes les trois dimensions (nombre de fichiers, taille et activité du dépôt), indépendamment, fournissent des défis de mise à l'échelle énormes et, ensemble, rendent incroyablement difficile de créer une expérience formidable. Avant le passage à Git, dans Source Depot, il a été réparti sur plus de 40 dépôts et nous avons eu un outil pour gérer les opérations qui les couvraient », a expliqué Harry.

    La transition de ses ingénieurs a été amorcée par vagues comme l’explique Harry : au départ, il y a trois mois, « nous avions tout le code dans un compte Git, quelques centaines d'ingénieurs l'utilisant et une petite fraction (<10%) de la charge de compilation quotidienne ».

    Ce qu’Harry considère comme le plus grand saut vers cette transition a eu lieu le 22 mars, lorsque Microsoft a déployé l'équipe Windows OneCore d'environ 2000 ingénieurs. « Ces 2000 ingénieurs ont travaillé dans Source Depot vendredi, sont rentrés chez eux pour le week-end et sont revenus lundi matin à une nouvelle expérience basée sur Git. Les gens de mon équipe ont retenu leur souffle durant tout ce week-end, en priant pour que nous ne soyons pas lynchés par une foule d'ingénieurs en colère qui se seraient montrés incapables d’accomplir quoi que ce soit ce fameux lundi. En vérité, l'équipe de Windows a fait un excellent travail en préparant des plans de sauvegarde en cas de malheur et, heureusement, nous n'avons pas eu à utiliser l'un d'entre eux. »

    Même s’il y a eu quelques soucis ce premier jour, Harry a été surpris de voir que la transition s’est passée sans accrocs dès le lundi. Un sondage a même été lancé auprès des ingénieurs pour savoir entre autres leur degré de satisfaction avec Git : d’après les résultats, ils se sont visiblement montrés quelque peu satisfaits.

    Une autre manière dont Microsoft a mesuré le succès a été d'examiner les « activités d'ingénierie » pour voir si les gens faisaient encore leur travail. « Par exemple, nous avons mesuré le nombre de “check-in” dans les branches officielles. Bien sûr, la moitié de l'équipe était toujours sur Source Depot et la moitié était sur Git, alors nous avons examiné l'activité combinée au fil du temps. Dans le tableau ci-dessous, vous pouvez voir la grande baisse des check-in de Source Depot et le grand saut dans les pull request de Git, mais dans l'ensemble, la somme des deux est restée raisonnable. Nous avons estimé que les données ont montré que le système fonctionnait et qu'il n'y avait pas de bloqueurs majeurs » .


    « Le 22 avril, nous avons lancé la vague suivante d'environ 1000 ingénieurs. Et puis, le 12 mai, nous avons lancé une autre vague de 300 à 400. Chaque vague successive suivait à peu près le même modèle et nous avons maintenant environ 3500 sur environ 4000 ingénieurs Windows sur Git. Les équipes restantes travaillent actuellement à des détails et tentent de déterminer le meilleur moment pour planifier leur migration, mais je m'attends à ce que, dans les prochains mois, nous achevions la migration de l'équipe d'ingénierie au complet ».

    Source : blog Microsoft

    Voir aussi :

    Microsoft annonce Git Virtual File System (GVFS) pour Windows 10, une solution destinée à supporter les énormes dépôts et bases de code

    Mise à jour du 17/11/2017 : Microsoft annonce travailler en collaboration avec GitHub pour porter son GVFS sur macOS et Linux

    « Beaucoup de choses se sont passées depuis que nous avons annoncé notre intention de développer GVFS pour le dépôt Windows », s’est réjoui Brian Harry,Vice President for Cloud Developer Services chez Microsoft. Avec Git Virtual File System (GVFS), plutôt que de télécharger l'intégralité du dépôt et de cocher tous les fichiers, le système se limite à télécharger de manière dynamique les portions dont vous avez besoin en fonction de ce que vous utilisez.

    Un système qui a donc intéressé plusieurs entités disposant d’énormes bases de code, mais qui était limité jusque là à Windows 10 (Anniversary Update au minimum). Cependant, Microsoft a annoncé que ce système sera bientôt disponible sur d’autres plateformes : « GitHub a annoncé qu'ils travaillaient sur l'ajout de la prise en charge de GVFS, rendant le Git évolutif disponible pour l'ensemble du monde open source. Ils vont également travailler en étroite collaboration avec nous pour améliorer encore GVFS et l'apporter aux utilisateurs Mac et Linux », a assuré Harry.

    Source : Microsoft
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    octobre 2011
    Messages
    170
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations forums :
    Inscription : octobre 2011
    Messages : 170
    Points : 136
    Points
    136

    Par défaut

    Quoi Microsoft n'utilise pas TFS ?!

  3. #3
    Membre émérite
    Profil pro
    Développeur
    Inscrit en
    mars 2012
    Messages
    1 499
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2012
    Messages : 1 499
    Points : 2 501
    Points
    2 501

    Par défaut

    TFS 2013 apporte le support de Git
    Si la réponse vous a aidé, pensez à cliquer sur +1

  4. #4
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 113
    Points : 18 869
    Points
    18 869

    Par défaut

    C'est bien, ça fera un homonyme avec GVfs (Gnome Vfs).

  5. #5
    Membre émérite
    Avatar de Voïvode
    Profil pro
    Inscrit en
    mars 2007
    Messages
    444
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 444
    Points : 2 510
    Points
    2 510

    Par défaut

    @ok.Idriss : Merci, je ne suis pas le seul à coincer sur cet acronyme.

  6. #6
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    mars 2013
    Messages
    3 283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : mars 2013
    Messages : 3 283
    Points : 75 945
    Points
    75 945

    Par défaut Microsoft fait le point sur ses contributions dans les performances de Git en 2017

    Microsoft fait le point sur ses contributions dans les performances de Git en 2017,
    quelle est celle qui vous intéresse le plus ?

    En février 2017, Microsoft a annoncé que son équipe de développement de Windows allait passer à l'utilisation du système de contrôle de version open source Git notamment en raison de Git Virtual File System (GVFS). Brian Harry, Vice President for Cloud Developer Services chez Microsoft, a expliqué que « GVFS, couplé à un ensemble d'améliorations à Git, permet à Git d’échelonner de TRÈS gros dépôts en virtualisant le dossier .git et le répertoire de travail. Plutôt que de télécharger l'intégralité du dépôt et de cocher tous les fichiers, il se limite à télécharger de manière dynamique les portions dont vous avez besoin en fonction de ce que vous utilisez. »

    Trois mois plus tard, Microsoft a publié un billet par l’entremise de Brian Harry où l’entreprise fait le point.

    Avant tout, il a rappelé que la base de code Windows comporte environ 3,5 millions de fichiers et, lorsqu'elle est enregistrée dans un compte Git, cet ensemble donne lieu à un dépôt de 300 Go. En outre, l'équipe de Windows compte environ 4000 ingénieurs et le système d'ingénierie produit 1760 « compilations de laboratoire » quotidiennes sur 440 branches en plus de milliers de compilations de validation de pull request.

    Le passage à Git a été influencé par un certain nombre de choses. En 2013, la société a entrepris son projet OneCore, unifiant ses différents domaines du développement de Windows et faisant en sorte que le système d'exploitation soit une plateforme en couches plus modulaire. À l'époque, Microsoft utilisait Source Depot, une version personnalisée du système de contrôle de la version Perforce commercial, pour tous ses projets majeurs.

    En novembre, Microsoft a annoncé travailler en collaboration avec GitHub pour porter son GVFS sur macOS et Linux. « Beaucoup de choses se sont passées depuis que nous avons annoncé notre intention de développer GVFS pour le dépôt Windows », s’est réjoui Brian Harry,Vice President for Cloud Developer Services chez Microsoft. Avec Git Virtual File System (GVFS), plutôt que de télécharger l'intégralité du dépôt et de cocher tous les fichiers, le système se limite à télécharger de manière dynamique les portions dont vous avez besoin en fonction de ce que vous utilisez.

    Un système qui a donc intéressé plusieurs entités disposant d’énormes bases de code, mais qui était limité jusque là à Windows 10 (Anniversary Update au minimum). Cependant, Microsoft a annoncé que ce système sera bientôt disponible sur d’autres plateformes : « GitHub a annoncé qu'ils travaillaient sur l'ajout de la prise en charge de GVFS, rendant le Git évolutif disponible pour l'ensemble du monde open source. Ils vont également travailler en étroite collaboration avec nous pour améliorer encore GVFS et l'apporter aux utilisateurs Mac et Linux », a assuré Harry.

    En ce début d’année, Microsoft veut faire le point sur ses contributions à Git.

    « Visual Studio Team Services (VSTS) héberge le plus grand référentiel Git au monde : le code source de Windows. Garder une copie primaire du code disponible dans le cloud et la rendre performante tout en étant mis à jour par plus de 4000 utilisateurs en même temps est une réalisation monumentale, mais elle n'est utile que si les ingénieurs peuvent utiliser le client Git principal sur leurs machines. Nous avons rendu cela possible en construisant GVFS.


    « Le référentiel Windows est plus important que n'importe quel autre référentiel Git par ordre de grandeur, ce qui a révélé quelques problèmes de performances dans Git principal que nous devions résoudre pour le faire fonctionner avec les grands référentiels que nous voyons chez Microsoft. Grâce au fait que Git est open source, nous avons pu l’améliorer pour tous les utilisateurs, sur toutes les plateformes en contribuant à ces modifications », a avancé Derick Stolee de Microsoft.

    « En revenant sur ce que nous avons accompli en 2017, je voulais partager les détails de certains de mes patchs préférés sur lesquels nous avons travaillé avec la communauté Git au cours de l'année écoulée », a-t-il annoncé.

    L’index

    L’index Git est une liste de tous les fichiers du hachage actuel et de l'objet attendu basé sur la zone de transfert actuelle. De nombreuses opérations Git chargent cet index en mémoire avant d'effectuer l'action demandée. Microsoft a trouvé plusieurs façons d'accélérer les interactions d'index.

    « L'index est une liste ordonnée de chemins. Sur chaque chargement d'index, Git vérifiait que la liste était toujours ordonnée. En sautant cette vérification, nous pouvons accélérer la charge d'index de 18 %. Lorsque l'index est reconstruit, les chemins sont écrits dans le bon ordre. Git vérifie les doublons sur les insertions, mais les doublons apparaissent consécutivement. En vérifiant la dernière entrée avant d'effectuer une recherche binaire, nous avons accéléré l'écriture d'index jusqu'à 20 %. Nous avons également réduit la fréquence à laquelle Git rejetait et rechargeait l'index. »

    Status et Checkout

    Deux des commandes Git les plus utilisées sont Status et Checkout , la première examine l'état du répertoire de travail pour voir ce qui est différent du HEAD actuel tandis que la seconde met à jour le répertoire de travail pour correspondre à un nouveau HEAD. Ces opérations sont appelées fréquemment, mais sont également très coûteuses lorsque vous travaillez sur de grands référentiels.

    « De nombreux outils, tels que Visual Studio Team Explorer, utilisent status pour présenter la liste des modifications disponibles pour la validation. Beaucoup de projets ont de grands répertoires remplis d'artefacts de builds qui sont ignorés par status en raison des fichiers .gitignore. Team Explorer utilise des indicateurs spéciaux pour afficher ces fichiers ignorés, mais cette liste peut être beaucoup plus grande que les fichiers importants. Nous avons ajouté de nouveaux drapeaux à status pour rendre cet appel plus rapide et maintenant d'autres outils peuvent également utiliser ces options. Pendant que nous examinions ce code, nous avons trouvé des moyens d'améliorer les performances de l'état git – jusqu'à 50 %.

    « Même avec ces accélérations, nous devons toujours parcourir le système de fichiers pour trouver l'état actuel des fichiers écrits. En fait, nous en AVIONS besoin. Nous avons ajouté un plug-in de surveillance de système de fichiers à git qui fournit à git une commande externe qui présente un instantané des changements du système de fichiers. Bien que nous nous concentrions sur l'intégration avec GVFS, cela peut aussi fonctionner avec des outils comme Watchman. »

    Source : blog Microsoft

    Et vous ?

    Quelle est la contribution qui vous intéresse le plus ?
    Quelle amélioration aimeriez-vous voir sur Git ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  7. #7
    Rédacteur
    Avatar de eclesia
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    2 070
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 2 070
    Points : 2 976
    Points
    2 976

    Par défaut

    Citation Envoyé par Stéphane le calme Voir le message
    Quelle amélioration aimeriez-vous voir sur Git ?
    1) des commandes humainement compréhensible.
    2) une documentation pour humain

    Sur les deux points Git n'a guère fait de progres en 10ans, c'est plutot même l'inverse, plus de commandes et encore plus d'arguments.
    Certes il y a pleins d'outils visuels maintenant mais pour ce qui est de la ligne de commande Git est de plus en plus loin derrière Mercurial ou encore Fossil.
    Systèmes d'Informations Géographiques
    - Projets : Unlicense.science GeotoolKit

    Pour un monde sans BigBrother IxQuick ni censure RSF et Les moutons

  8. #8
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 382
    Points : 6 571
    Points
    6 571

    Par défaut

    Je n'osais pas le dire l'utilisant peu (on est majoritairement sous clearcase) mais puisque eclesia enfonce la porte !
    Je ne fais rien en ligne de commande tellement c'est imbitable... Tout avec un GUI, et pourtant sous Clearcase c'est tout l'inverse, je fais tout en ligne de commande (tout ça pour dire que ce n'est pas par feignantise...).
    Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur.

  9. #9
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 113
    Points : 18 869
    Points
    18 869

    Par défaut

    Perso j'adore la ligne de commande de git et la trouve beaucoup plus interractive et puissante que svn.
    Par contre effectivement ça se devine pas mais c'est d'une puissance... une fois connue la syntaxe ne pose plus de problème.

    Je pense rédiger une FAQ un jour sur DVP :p

  10. #10
    Responsable Qt


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherches
    Inscrit en
    août 2008
    Messages
    22 703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherches
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 22 703
    Points : 127 086
    Points
    127 086

    Par défaut

    Citation Envoyé par ok.Idriss Voir le message
    une fois connue la syntaxe ne pose plus de problème.
    Juste à titre d'information, ça t'a pris combien de temps pour arriver à ce niveau de maîtrise de Git ?
    Vous souhaitez participer aux rubriques Qt ou PyQt (tutoriels, FAQ, traductions), HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  11. #11
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 113
    Points : 18 869
    Points
    18 869

    Par défaut

    C'est difficile à évaluer parce que t'apprends au fur et à mesure de tes besoins. Et perso j'utilises beaucoup le shell (bash) et la commande history et Ctrl+R pour retrouver les commandes, ça finit par rentrer tout seul.

    Si ça peut aider, les principales que j'utilises tout les jours (avec un shell intégré à mon IDE) et que du coup je connais par coeur et que du coup j'ai écrit de tête sans vérifier les coquilles :

    Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    git clone ... # obviously :p
    git checkout -b XXXX # création d'une branche XXXX dérivée de la branche courrante
    git branch -D ZZZZ # supprimer une branche ZZZZ
    git checkout YYYY # basculer sur la branche YYYYY
    git add . ; git commit -m "My amazing feature" ; 
    git pull --rebase [origine YYYY] # mettre à jour à partir du repo distant
    git merge XXXX # merger les commits de XXXX dans la branche YYYY
    git push origin YYYY # pousser la branche YYYY sur le repo distant
    git log # afficher l'historique des commits
    git cherry-pick {revision} # reporter un commit sur la branche courrante
    git revert {revision} # retour arrière

    Et une qui mérite que l'on s'y attarde un peu plus : le rebase interactif :

    Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
    git rebase -i HEAD~{nombre de revision que l'on veux modifier}

    L'éditeur qui suit explique très bien ce qu'on peux faire : squash/ fixup (fusionner des commits successifs), reword (changer le message, équivaut au git commit --amend quand on vient de faire le commit), pick (concerver)

    Pour le diff et l'historique je privilégie mon IDE (Intellij) parce que quand je suis sur le code, c'est plus pratique (mais sinon pas compliqué : git diff, git blame...).
    Voilà pour le reste, je google quand j'ai besoin. Je vous laisses estimer le temps que ça vous prend pour maitriser tout ça mais honnêtement, ça ne casses pas trois pâtes à un canard :p
    Et on peux scripter pour se faire des raccourcis

    Pour en revenir à mon propos précédent : je trouve ça beaucoup plus simple que SVN pour faire des reports ou des retours arrière (grâce aux squash et aux cherry-pick entre autres qui permettent de réduire le nombre de révisions à reporter et aussi parce que contrairement à SVN une branche ou un tag != une working copy avec tout les fichiers dupliqués, juste une liste de révisions). Sans compter la puissance de l'éco-système CI qui existe autour avec gitlab/gitlab-ci, github/travis, bitbucket & cie.

  12. #12
    Nouveau membre du Club Avatar de MKuser53
    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    décembre 2016
    Messages
    33
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Mayenne (Pays de la Loire)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : décembre 2016
    Messages : 33
    Points : 26
    Points
    26

    Par défaut

    Il est possible aussi d'utiliser des alias dans le .gitconfig
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    [alias]
    	ci = commit -m
    	done = commit -a -m
    	st = status -sb
    	co = 'checkout'
    	pr = pull --rebase=preserve
    	lg = log --graph --pretty=tformat:'%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ar)%Creset'
    	accept-ours = "!f() { [ -z \"$@\" ] && set - '.'; git checkout --ours -- \"$@\"; git add -u -- \"$@\"; }; f"
    	accept-theirs = "!f() { [ -z \"$@\" ] && set - '.'; git checkout --theirs -- \"$@\"; git add -u -- \"$@\"; }; f"
    	moi = log --pretty=format:'%Cred%h%Creset -%Creset %s %Cgreen(%cD) %C(bold blue)<%an>%Creset' --since='1 week ago' --author moi
    	rdiff = diff origin/master..master
    	wdiff = diff --word-diff=plain
    	ignored = ls-files --others -i --exclude-standard
    	ol = add . --all
    	win = config --global core.autocrlf true
    	unix = config --global core.autocrlf input

  13. #13
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    280
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Belgique

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 280
    Points : 880
    Points
    880

    Par défaut

    Citation Envoyé par ok.Idriss Voir le message
    C'est difficile à évaluer parce que t'apprends au fur et à mesure de tes besoins. Et perso j'utilises beaucoup le shell (bash) et la commande history et Ctrl+R pour retrouver les commandes, ça finit par rentrer tout seul.

    Si ça peut aider, les principales que j'utilises tout les jours (avec un shell intégré à mon IDE) et que du coup je connais par coeur et que du coup j'ai écrit de tête sans vérifier les coquilles :

    Code bash : Sélectionner tout - Visualiser dans une fenêtre à part
    git add . ; git commit -m "My amazing feature"
    Perso j'utilise plutôt git commit -am "My amazing feature" :-)

    Ta liste correspond grosso modo à l'utilisation que je fais de git, sauf cherry-pick, que je ne connaissais pas ^^

    Par contre j'ajouterai `git stash` et `git stash pop` :-)

  14. #14
    Rédacteur

    Avatar de ok.Idriss
    Homme Profil pro
    IS Consultant
    Inscrit en
    février 2009
    Messages
    5 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : IS Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 5 113
    Points : 18 869
    Points
    18 869

    Par défaut

    Ouais +1 pour stash, je l'utilise pas mal aussi :p

    Sinon commit -am perso je l'utilises pas à cause des nouveaux fichiers :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    $ touch yoyo
    $ git commit -am "ssss"
    Missing arguments : [file1.java file2.java ...]
    
    On branch XXXXX
    Untracked files:
    	yoyo
    
    nothing added to commit but untracked files present
    $ git add .; git commit -m "ssss"
    Missing arguments : [file1.java file2.java ...]
    
    Git add xxxxx/yoyo
    [XXXX f25c35d] ssss
     1 file changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 yoyo

  15. #15
    Membre confirmé
    Profil pro
    Inscrit en
    août 2008
    Messages
    165
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2008
    Messages : 165
    Points : 481
    Points
    481

    Par défaut

    Sinon Pro Git explique toute l'utilisation courante en 50 pages.
    C'est ce livre qui m'a mis le pied à l'étrier sans douleur.

  16. #16
    Membre confirmé
    Inscrit en
    janvier 2006
    Messages
    226
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 226
    Points : 529
    Points
    529

    Par défaut performances de Git ... sous Windows

    Microsoft fait le point sur ses contributions dans les performances de Git en 2017
    La bonne blague. Microsoft pourrait commencer par chercher une solution pour qu'un git rebase, qui prend quelques secondes sous Linux, ne prenne plus trois plombes quand le dépôt est sur un NTFS sous Windows.
    Sérieux, quand on fait un rebase interactif sur plusieurs dizaines de commit, ça va des fois plus vite de créer une branche temporaire, faire une série de cherry-pick ou même de git-am et de finalement virer la branche originale et renommer la nouvelle! Aberrant! (je parle du temps pendant lequel la commande s'exécute, pas celui pendant lequel l'utilisateur travaille)
    J'ai même des VM linux qui sont juste là pour que git soit plus rapide... que son équivalent Windows sur la machine hôte!

Discussions similaires

  1. ingénieur dédié php ?
    Par Olitec dans le forum Salaires
    Réponses: 5
    Dernier message: 10/10/2011, 17h12
  2. Ingénieur recherche et développement junior
    Par GDMINFO dans le forum Demandes
    Réponses: 0
    Dernier message: 03/10/2007, 13h12
  3. Salaire ingénieur étude et développement à Nice
    Par Death83 dans le forum Salaires
    Réponses: 13
    Dernier message: 12/06/2007, 15h44
  4. Salaire d'ingénieur dans le développement web
    Par Death83 dans le forum Salaires
    Réponses: 12
    Dernier message: 29/09/2006, 01h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo