Meilleures pratiques pour utiliser Git avec Intellij Idea

Question

En résumé : quels sont les bonnes pratiques pour utiliser Intellij Idea (9) et Git ?

Contexte

Nous avons récemment mis à niveau vers la version 9 d'Intellij idea et avons commencé à utiliser Git pour une nouvelle fonctionnalité sur un projet existant.

Nous utilisons principalement la ligne de commande Git pour mieux apprendre l'outil. Mais nous avons pensé demander l'avis général pour découvrir quelles sont les meilleures pratiques pour Git avec Idea.

L'interface Idea est similaire pour CVS et Git, mais les implémentations sous-jacentes diffèrent un peu.

Exemples de questions

Par exemple : -Avec CVS, quand nous avions plusieurs versions d'un produit, chacun de nous avait une copie locale des branches 1-0, 2-0, 3-0, etc., chacune avec ses propres fichiers Intellij (c'est-à-dire .ipr, .iws, etc.). La "manière Git" semble être d'avoir un seul projet et d'utiliser la commande 'git branch' pour changer de branche. C'est bien, mais cela crée une énorme charge de travail pour Idea (car il doit recharger chaque fichier modifié, y compris les jars enregistrés) lorsque vous changez de branche. Ainsi : avez-vous toujours un projet séparé (avec .git) pour chaque "version majeure" ou avez-vous un seul projet et utilisez-vous "git branch" ?

-Est-il une bonne idée d'utiliser Autostash ?

-Ajoutez-vous automatiquement chaque modification à votre commit Git ? ou utilisez-vous "git add" plus tard ?

-Faites-vous un rebase ?

-Meilleure façon de fusionner ?

-Autres conseils/astuces/ce qui fonctionne pour vous, etc.

Commentaires finaux

Nous "pensons toujours en CVS", donc une partie de cela consiste à s'habituer à Git ; une partie consiste à s'habituer à l'interface utilisateur d'Idea pour Git.

Il s'agit de questions assez rudimentaires car nous utilisons principalement la ligne de commande. J'ai également entendu dire qu'Idea 10 a des outils d'intégration Git meilleurs/plus forts/plus rapides.

Merci

Answer 1

Voici ce que nous avons trouvé après plusieurs semaines de Git/Idea. J'ai fait de cela un wiki communautaire. Merci de contribuer avec vos 2 couronnes/centimes/pfennigs/cents.

Note: Je réponds à ma propre question car je cherchais ces listes à puces faciles à utiliser.

Présupposition

Idea est un super outil. Personne ici ne se plaint. Juste observer.

Meilleures pratiques

• À ce stade (9.0.3) Git avec Idea est tout simplement plus difficile à utiliser que SVN avec Idea. Cela provient en partie de la complexité de Git (par rapport à SVN), en partie parce que les outils d'Idea ne font pas tout dans le monde git.

• Vous devrez donc utiliser la ligne de commande

• L'outil de fusion d'Idea fonctionne beaucoup mieux que la fusion en ligne de commande ou même en utilisant mergetool (en utilisant meld ou mergetool). La raison : vous avez beaucoup plus de liberté pour travailler dans l'environnement 'idea' plutôt que de fixer un problème à la fois.

• N'oubliez pas de synchroniser dans Idea (ctrl-alt-y) lorsque vous mettez à jour l'arborescence de travail depuis la ligne de commande

• Observer la Console Git dans Idea pour apprendre les astuces git d'Idea; Idea exécute des commandes git ici. (Affichage de contrôle de version, onglet Console) :

exemple :

13:30:58.234: git log -M --follow --name-only --pretty=format:%H%x00%ct%x00%an%x20%x3C%ae%x3E%x00%cn%x20%x3C%ce%x3E%x00%s%n%n%b%x00 --encoding=UTF-8 -- src/jsp/workspaces/include/edit.jsp
13:31:02.437: cd J:\projects\PE-GIT\pe
13:31:02.437: git annotate -p -l -t -M HEAD -- src/jsp/workspaces/include/edit.jsp

• Malheureusement, Idea n'a pas de bons outils pour "fusionner des conflits dans les commits amont" dans la version 9.0.3

Exemple :

• Alice travaille, effectue un commit (en local) du fichier A, effectue un commit du fichier B, effectue un commit du fichier C
• Bob travaille, effectue un commit du fichier C, effectue un commit du fichier D, effectue un commit du fichier E
• Alice pousse ses modifications
• Bob tire ses modifications

En venant de CVS/SVN, je m'attendais à ce que l'outil de différenciation pratique d'Idea apparaisse. Non. Au lieu de cela, git/Idea lancent un avertissement, donc j'utilise généralement "git mergetool" (meld ou sur linux, tortoiesmerge sur windows).

Note: Peut-être qu'Idea propose une meilleure solution. N'hésitez pas à me corriger. Note pour les motivés : pouvez-vous configurer .gitconfig pour utiliser l'outil de différenciation d'Idea ?

Stashing

• La fonctionnalité "Ranger" d'Idea duplique "Git Stash". Les deux semblent similaires. Les deux utilisent des patchs. Vous voudrez probablement utiliser l'un ou l'autre. Je n'ai pas encore compris l'avantage de l'un par rapport à l'autre.

Gros Anciens Projets

• Si vous travaillez sur un projet vieux de dix ans récemment migré vers Git, avec des fichiers jar vérifiés dans le scm (c'est-à-dire précédemment vérifiés dans CVS/SVN, où log4j-1.0.jar est dans BRANCHE-2-0 et la ligne principale a log4j-9.0.jar), PROCÉDEZ AVEC PRUDENCE si vous voulez vérifier la "version 2.0" de votre projet. Idea doit décharger tous les jars "principaux" et recharger les jars vérifiés en 2.0. Cela prend une éternité.

Autres petites choses

• Les menus/UI d'Idea montrent toujours "git init..." même si vous avez déjà initialisé Git. C'est déroutant, mais ignorez-le.

• Vous ne pouvez pas avoir la même arborescence de travail à la fois dans Git et CVS/SVN (bien que l'interface utilisateur semble le suggérer). J'ai/nous avons essayé cela lors d'une phase initiale de "essayons git et utilisons toujours CVS comme plan de secours". Cela n'a pas fonctionné

Answer 2

Tout d'abord, vous pouvez trouver de nombreuses informations sur git dans les livres de référence gratuits en ligne :

• http://progit.org/
• http://book.git-scm.com/
• http://www-cs-students.stanford.edu/~blynn/gitmagic/

Note : les "bonnes pratiques" de Git et le processus de travail sont totalement indépendants de l'IDE que vous utilisez. Heureusement, IDEA est un excellent IDE et la plupart des fonctions utiles de Git sont bien implémentées (rebase, stash, etc.)

Concernant vos questions sur git-flow, vous pensez comme avec un VCS centralisé.

Git est un Système de Contrôle de Version Distribué. Vous devez donc "penser local d'abord".

Pour les commits, cela n'a pas vraiment d'importance si vous ajoutez chaque fichier à l'index immédiatement ou plus tard, si vous committez fréquemment ou non. C'est votre travail local, et vous pouvez l'organiser comme vous le préférez.

Ce qui est important, c'est d'avoir des commits propres lorsque vous êtes sur le point de pousser votre travail (le rendre visible aux autres développeurs).

Lorsque vous êtes sur le point de pousser, vous pouvez corriger toute votre historique depuis le dernier push (avec rebase, par exemple).

Par exemple (si vous avez oublié de amender le commit précédent) : - commit "une super fonction" - commit "oups : oubli d'un fichier" - commit "correction d'un bug"

Avant de pousser ces 3 commits, vous pouvez fusionner ces commits en utilisant un rebase interactif avec IDEA. Ainsi, les 2 derniers commits seront inclus dans le premier.

Note : vous pouvez modifier votre historique tant que vous n'avez pas poussé. Après, vous pouvez toujours le faire mais c'est une très mauvaise idée (et si vous ne forcez pas Git, le prochain push sera refusé), car cela pourrait détruire l'historique de vos collègues (s'ils ont récupéré/fusionné votre travail).

Concernant un flux de travail Git commun, je vous recommande cet article intéressant : http://nvie.com/posts/a-successful-git-branching-model/