Meilleures pratiques pour utiliser Git avec Intellij Idea
En bref: quelles sont les meilleures pratiques pour utiliser Intellij Idea (9) et Git?
Contexte
Nous avons récemment mis à niveau vers Intellij idea version 9 et avons commencé à utiliser Git pour une nouvelle fonctionnalité sur un projet existant.
Nous utilisons largement la ligne de commande git pour mieux apprendre l'outil. Mais nous avons pensé que nous choisirions l'esprit de la ruche pour découvrir quelles sont les meilleures pratiques pour git avec idée.
L'interface utilisateur Idea est similaire pour CVS et Git, mais les implémentations sous-jacentes diffèrent un peu.
Exemples de questions
Par exemple: -Avec CVS, lorsque nous avions plusieurs versions d'un produit, chacun de nous aurait une copie locale des branches 1-0, 2-0, 3-0, etc., chacune avec ses propres fichiers Intellij (c.-à-d. .ipr, .iws, etc.). La "manière git" semble avoir un projet et utiliser "git branch" pour changer de branche. C'est très bien, mais cela crée une énorme surcharge pour l'idée (car il doit recharger chaque fichier modifié, y compris les fichiers jars enregistrés) lorsque vous changez de branche. Donc: avez-vous toujours un projet distinct (avec .git) pour chaque "version majeure" ou avez-vous un projet et utilisez "git branch"?
-C'est une bonne idée d'utiliser Autostash?
-Ajoutez-vous automatiquement chaque modification à votre git commit? ou utiliser "git add" plus tard?
-Tu rebases?
-La meilleure façon de fusionner?
-Toutes autres astuces/conseils/ce qui fonctionne pour vous, etc.
Commentaires finaux
Nous "pensons toujours dans les cv", donc une partie de cela est de s'habituer à git; une partie s'habitue à l'interface utilisateur d'Idea pour git.
Ce sont des questions assez rudimentaires car nous utilisons toujours la ligne de commande principalement. J'ai également entendu que l'idée 10 avait des outils d'intégration Git meilleurs/plus forts/plus rapides
Merci
Voici ce que nous avons trouvé après plusieurs semaines de Git/Idea. J'en ai fait un wiki communautaire. Veuillez ajouter vos 2 couronnes/centimètres/pfennings/cents.
Remarque: je réponds à ma propre question parce que j'ai cherché ces puces faciles à utiliser.
Présupposition
L'idée est un excellent 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. Une partie provient de la complexité de Git (vs SVN), en partie parce que les outils d'Idea ne font pas tout dans le monde git.
Ainsi, vous devrez 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 un "environnement d'idées" plutôt que de fixer une charpie à la fois.
N'oubliez pas de synchroniser dans Idea (ctrl-alt-y) lorsque vous mettez à jour l'arborescence de travail à partir de la ligne de commande
Regarder la console Git pour apprendre les astuces git de l'idée; idea y exécute les commandes git (vue 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 les conflits dans les commits en amont" dans 9.0.3
Exemple:
- Alice fonctionne, valide (localement) le fichier A, valide le fichier B, valide le fichier C
- Bob fonctionne, valide le fichier C, valide le fichier D, valide le fichier E
- Alice pousse ses changements
- Bob tire ses changements
Venant de CVS/SVN, je m'attendais à ce qu'un outil différent d'idées pratique apparaisse. Au lieu de cela, git/idea lève un drapeau rouge, je finis généralement par utiliser "git mergetool" (meld od sous linux, tortoiesmerge sous windows).
Remarque: Idea offre peut-être un meilleur moyen. Veuillez me redresser. Note aux motivés: pouvez-vous configurer .gitconfig pour utiliser l'outil de différenciation d'Idea?
Stashing
- Idées La fonctionnalité "Shelve" duplique "Git Stash". Les deux semblent similaires. Les deux utilisent des correctifs. Vous souhaitez probablement utiliser l'un ou l'autre. Je n'ai pas compris l'avantage de l'un ou de l'autre
Grands vieux projets
- Si vous travaillez sur un projet vieux de dix ans récemment migré vers Git, avec des fichiers jar archivés dans la scm (c'est-à-dire précédemment archivés dans CVS/SVN, où log4j-1.0.jar est dans BRANCH-2-0 et la ligne principale a log4j- 9.0.jar), PROCÉDER AVEC ATTENTION si vous souhaitez extraire la "version 2.0" de votre projet. L'idée doit décharger tous les pots "principaux" et recharger les pots vérifiés à la version 2.0. Cela prend pour toujours.
Autres petits trucs
Les menus d'idées/l'interface utilisateur affichent 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 dans Git et CVS/SVN (bien que l'interface utilisateur puisse sembler le suggérer). J'ai/nous avons essayé ceci pendant une phase initiale "essayons git et utilisons toujours CVS comme plan de sauvegarde". Ça n'a pas marché
Tout d'abord, vous pouvez trouver de nombreuses informations sur git dans les livres de référence en ligne gratuits:
Remarque: les "bonnes pratiques" et le workflow de Git sont totalement indépendants du 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.)
À propos de vos questions git-flow, vous pensez comme avec VCS centralisé.
Git est un système de contrôle de version distribué . Donc, vous devez " penser d'abord local ".
Pour les validations, cela n'a pas vraiment d'importance si vous ajoutez chaque fichier à l'index immédiatement ou ultérieurement, si vous effectuez fréquemment ou non. C'est votre travail local, et vous pouvez l'organiser à votre guise.
Ce qui est important, c'est d'avoir des validations propres lorsque vous êtes sur le point de pousser votre travail (de l'exposer aux autres développeurs).
Lorsque vous êtes sur le point de pousser, vous pouvez corriger tout votre historique depuis la dernière poussée (avec rebase, par exemple).
Par exemple (si vous avez oublié de modifier commit précédent): - commit "une super fonction" - commit "oups: oublié un fichier" - commit "bug correction"
Avant de pousser ces 3 validations, vous pouvez fusionner ces validations, en utilisant un rebase interactif avec IDEA. Ainsi, les 2 derniers commits seront inclus dans le premier.
Remarque: vous pouvez modifier votre historique sans avoir poussé. Après vous pouvez toujours mais c'est une très mauvaise idée (et si vous ne forcez pas Git, la prochaine poussée sera refusée), car cela pourrait détruire l'historique de vos collègues (s'ils ont récupéré/fusionné votre travail).
À propos d'un flux de travail Git commun, je vous recommande ce bon article: http://nvie.com/posts/a-successful-git-branching-model/