Comme le veut la tradition, je vous souhaite la bienvenue, futurs ingénieurs logiciels seniors. Aujourd'hui, nous allons parler de la suite logique de mon article sur Git . Je recommande également de lire le matériel sur les stratégies de branchement que j'ai publié plus tôt. Dans l'article sur Git, j'ai décrit comment l'utiliser en ligne de commande, et aujourd'hui je vais vous montrer comment faire tout cela dans Intellij IDEA. Au début de mon parcours en tant que développeur, j'utilisais la ligne de commande et pensais que je n'avais pas besoin d'utiliser l'interface utilisateur pour cela. Après tout, tout est clair et ainsi... Mais c'était exactement jusqu'au moment où j'ai commencé à utiliser Git dans Intellij IDEA... Je tiens à dire tout de suite que je vais décrire mon expérience personnelle. Il existe plusieurs options pour résoudre les mêmes problèmes avec Intellij IDEA, et si vous savez comment mieux faire ce que je décris dans l'article, écrivez dans les commentaires et nous en discuterons.
Notes introductives nécessaires :
Lisez, répétez et comprenez l'article sur git . Cela permettra de garantir que tout est déjà configuré et prêt à fonctionner.
Installez Intellij IDEA.
Réservez une heure de temps personnel pour une absorption complète.
Pour le travail, prenons le projet de démonstration que j'ai utilisé pour l'article sur git. MISE À JOUR:Au moment de la publication, la nouvelle interface utilisateur de Github sera déjà disponible et certaines icônes ne seront pas là où elles sont affichées dans l'article. Ne vous inquiétez pas : il vous suffira soit de ne pas passer à la nouvelle interface utilisateur, soit de la rechercher.
Cloner le projet localement
Il y a deux options ici.
Si vous avez déjà un compte Github et que vous souhaitez pousser quelque chose plus tard, il est préférable de vous confier le projet et de cloner votre copie. Comment faire un fork - J'ai décrit dans cet article dans le chapitre un exemple de flux de travail de fork .
Clonez depuis mon référentiel et faites tout localement sans pouvoir transférer le tout sur le serveur. Après tout, ce sera mon référentiel))
Pour cloner un projet depuis Github, vous devez copier le lien vers le projet et le transmettre à IntelliJ IDEA :
Copiez l'adresse du projet :
Ouvrez Intellij IDEA et sélectionnez Obtenir à partir du contrôle de version :
Copiez et collez l'adresse du projet :
Vous serez invité à créer un projet Intellij IDEA. Nous acceptons l'offre :
Puisqu'il n'y a pas de système de build et que ce n'est pas le cadre de l'article, sélectionnez Créer un projet à partir de sources existantes :
Ensuite, il y aura une peinture à l'huile comme celle-ci : Nous avons réglé le problème du clonage, maintenant nous pouvons regarder autour de nous.
Premier aperçu d'Intellij IDEA en tant qu'interface utilisateur Git
Examinez de plus près le projet cloné : vous pouvez déjà y obtenir de nombreuses informations sur le système de contrôle de version. Le premier est le panneau de contrôle de version dans le coin inférieur gauche. Vous pouvez y trouver toutes les modifications locales et obtenir une liste des commits (analogue au git log). Passons à la conférence Log . Il existe une certaine composante visuelle qui permet de comprendre exactement comment s'est déroulé le processus de développement. Par exemple, vous pouvez voir qu'une nouvelle branche a été créée avec un en-tête commit ajouté à txt , qui a ensuite été fusionné dans la branche master. Si vous cliquez sur un commit, dans le coin droit, vous pouvez voir toutes les informations sur le commit : toutes les modifications et ses métadonnées. De plus, vous pouvez voir quelles modifications ont été apportées. D’ailleurs, le conflit y a été résolu. IDEA le montre également parfaitement. Si vous double-cliquez sur le fichier qui a été modifié lors de ce commit, nous verrons comment le conflit a été résolu : on remarque qu'à droite et à gauche il y avait deux versions du même fichier qui devaient être fusionnées en une seule. Et au milieu se trouve le résultat final. Lorsqu'un projet comporte de nombreuses branches, commits et utilisateurs qui travaillent dans le projet, vous devez effectuer une recherche séparément par branche (branche), utilisateur (utilisateur) et date (date) : Et la dernière chose que je veux expliquer avant de commencer est de savoir comment comprendre dans quelle branche nous sommes. Je vais vous donner une minute pour chercher... l'avez-vous trouvé ? Est-ce que vous abandonnez ? :D Dans le coin inférieur droit, il y a un bouton Git: master , où après Git: il indique sur quelle branche se trouve actuellement le projet. Si vous cliquez sur le bouton, vous pouvez faire beaucoup de choses utiles : passer à une autre branche, en créer une nouvelle, renommer une branche existante, etc.
Travailler avec le référentiel
Touches de raccourci utiles
Pour continuer à travailler, vous devez vous rappeler quelques raccourcis clavier très utiles :
ctrl + t - récupère les dernières modifications d'un référentiel distant (git pull).
ctrl + k - valider/afficher toutes les modifications actuellement disponibles. Cela inclut à la fois les fichiers non suivis et modifiés (voir mon article sur git, ceci y est décrit) (git commit).
ctrl + shift + k est une commande permettant de transmettre les modifications à un référentiel distant. Tous les commits créés localement et qui ne sont pas encore sur le site distant seront proposés en push (git push).
alt + ctrl + z - annule les modifications dans un fichier spécifique à l'état du dernier commit créé dans le référentiel local. Si vous sélectionnez l'intégralité du projet dans le coin supérieur gauche, vous pouvez annuler les modifications apportées à tous les fichiers.
Que voulons-nous?
Pour travailler, il faut maîtriser le script de base, utilisé partout. La tâche consiste à implémenter une nouvelle fonctionnalité dans une branche distincte et à la transférer vers un référentiel distant (vous devez ensuite créer une autre demande d'extraction pour la branche principale, mais cela dépasse le cadre de notre article). Qu'est-ce que je dois faire?
Obtenez toutes les modifications actuellement dans la branche principale (master, par exemple).
Sur la base de ce principal, créez-en un distinct pour votre travail.
Implémenter de nouvelles fonctionnalités.
Accédez à la branche principale et vérifiez s'il y a eu de nouveaux changements pendant que vous travailliez. Si ce n'est pas le cas, alors tout va bien, et si c'était le cas, alors nous procédons comme suit : nous allons dans la branche de travail et rebasons les modifications de la branche principale vers la nôtre. Si tout s’est bien passé, tant mieux. Mais il pourrait y avoir des conflits. Et ils peuvent être résolus à l'avance sans perdre de temps sur un référentiel distant.
Il semblerait, pourquoi faire ça ? Il s'agit d'une règle de bonne forme, qui évite que des conflits n'apparaissent après avoir poussé votre branche vers le dépôt local (il y a bien sûr une chance qu'ils existent toujours, mais elle devient beaucoup plus petite).
Transférez vos modifications vers un référentiel distant.
Ce qui se passe ensuite dépend de vos objectifs et de votre imagination.
Recevoir les modifications d'un serveur distant ?
J'ai ajouté une description au README avec un nouveau commit et je souhaite recevoir ces modifications. Un choix est proposé entre fusionner et rebase si des modifications ont été apportées à la fois dans les référentiels locaux et distants. Sélectionnez une fusion. Entrez ctrl + t : En conséquence, vous pouvez voir comment le README a changé, c'est-à-dire les modifications du référentiel distant ont été extraites et dans le coin inférieur droit, vous pouvez voir tous les détails des modifications provenant du serveur.
Créer une nouvelle branche basée sur master
Tout est simple ici.
Allez dans le coin inférieur droit et cliquez sur Git: master , sélectionnez + New Branch .
Laissez la case à cocher Branche Checkout et écrivez le nom de la nouvelle branche. Pour moi, ce serait un outil readme-améliorateur .
Après cela, Git: master deviendra Git: readme-improver .
Simuler un travail parallèle
Pour que des conflits apparaissent, il faut que quelqu'un les crée :D Je vais éditer le README avec un nouveau commit via le navigateur et ainsi simuler un travail parallèle. On dit que quelqu'un, pendant mon travail, a apporté des modifications au même fichier que moi, ce qui entraînera un conflit. Je vais supprimer le mot « entièrement » de la ligne 10.
Implémentez votre fonctionnalité
La tâche consiste à modifier le README et à ajouter une description au nouvel article, c'est-à-dire que le travail dans git est effectué via Intellij IDEA. Ajoutez ceci : les modifications sont terminées, vous pouvez maintenant créer un commit. Appuyez sur le raccourci clavier ctrl + k , nous obtenons : Avant de créer un commit, vous devez regarder attentivement ce qui est proposé dans cette fenêtre. J'ai spécifiquement ajouté une flèche pour vous montrer où chercher. Il y a beaucoup de choses intéressantes là-bas. Dans la section Commit Message , nous écrivons le texte du commit, et pour qu'il soit créé, vous devez cliquer sur le bouton Commit . Je n'ai toujours pas trouvé comment faire cela avec un raccourci clavier, donc si quelqu'un le trouve, écrivez, je serai très heureux. Nous écrivons que le README a changé et créons un commit. En conséquence, une alerte apparaîtra dans le coin inférieur gauche avec le nom du commit :
Vérifiez si la branche principale a changé
Nous avons terminé la tâche, ça marche, nous avons écrit les tests, tout va bien. Mais avant de pousser vers le serveur, vous devez vérifier s'il y a eu des changements dans la branche principale pendant cette période. Comment cela pourrait-il arriver? C’est très simple : quelqu’un s’est vu confier une tâche après vous, et cette personne l’a fait plus vite que vous. Par conséquent, nous passons à la branche master. Pour ce faire, vous devez faire dans le coin inférieur droit ce qui est indiqué dans la figure ci-dessous : Dans la branche master, appuyez sur ctrl + t pour obtenir ses dernières modifications depuis le serveur distant. Si vous regardez les modifications apportées, vous pouvez facilement remarquer ce qui s'est passé : comme vous pouvez le voir, le mot « complètement » a été supprimé. Peut-être que c’est quelqu’un du marketing qui a décidé que cela ne pouvait pas être écrit ainsi et a confié aux développeurs la tâche de le mettre à jour. Nous disposons désormais localement de la dernière version de la branche master. Revenons à readme-improver . Nous devons maintenant rebaser les modifications de la branche master vers la nôtre. Nous le faisons : Si vous avez tout suivi correctement avec moi, le résultat devrait être un conflit dans le fichier README : Il y a aussi ici beaucoup d'informations qui doivent être comprises et absorbées. Cela affiche une liste (dans notre cas d'un élément) des fichiers qui ont des conflits. Nous pouvons choisir trois options :
acceptez le vôtre - n'acceptez que les modifications du readme-improver.
acceptez les leurs - n'acceptez que les modifications du maître.
fusionner - choisissez vous-même ce que vous souhaitez conserver et ce que vous souhaitez supprimer.
Ce qui a changé là-bas n'est pas clair, et si les modifications sont dans le maître, alors elles sont nécessaires là-bas, et nous ne pouvons pas simplement accepter nos modifications, nous sélectionnons donc fusionner : Ici, vous pouvez voir qu'il y a trois parties :
Ce sont des changements par rapport au readme-improver.
Résultat. Pour l’instant, c’est la même chose qu’avant les changements.
Modifications de la branche principale.
Nous devons collecter le résultat de manière à ce qu'il satisfasse tout le monde. Par conséquent, nous avons étudié ce qu’ils ont fait AVANT nous et avons réalisé qu’ils avaient simplement supprimé le mot « complètement ». Bon ok, pas de problème. Cela signifie que nous allons le supprimer et ajouter nos modifications. Dès que nous corrigeons le résultat, vous pouvez cliquer sur Appliquer . Après cela, une notification apparaîtra indiquant que le rebase a réussi : C'est ainsi que nous avons résolu notre premier conflit via Intellij IDEA :D
Transférer les modifications vers un serveur distant
L'étape suivante consiste à transmettre les modifications au serveur distant et à créer une pull request. Pour ce faire, appuyez simplement sur ctrl + shift + k , après quoi nous obtenons : À gauche, il y aura une liste des commits qui n'ont pas été poussés vers le référentiel distant, et à droite, il y aura tous les fichiers qui ont été modifié. C'est tout : cliquez sur Push , et vous serez heureux :) Si le push réussit, il y aura une notification comme celle-ci dans le coin inférieur droit :
Partie bonus
Je ne voulais pas au départ ajouter la création d'une pull request à l'article, mais cela s'avère peu complet de ce fait. Par conséquent, nous allons dans le référentiel GitHub (si c'est le vôtre, bien sûr)))) et voyons que GitHub sait déjà quoi nous proposer : cliquez sur Compare & pull request , puis cliquez sur Create pull request . Grâce au fait que nous avons résolu les conflits à l'avance, lors de la création d'une pull request, vous pouvez désormais la fusionner immédiatement : c'est tout ce que je voulais vous dire cette fois. Bien sûr, je viens d'ouvrir la porte et de vous en montrer une petite partie. Vous trouverez le reste vous-même selon vos besoins. Comme d'habitude, je vous invite à vous abonner à mon compte GitHub , où je publie des projets basés sur diverses technologies que j'utilise au travail. J'ai récemment eu une réalisation personnelle : mon projet a déjà été évalué par plus d'une centaine de développeurs. C'est un sentiment de joie incroyable que quelqu'un utilise ce que vous avez créé. Et l'utilise pour de bon.
Nous avons réglé le problème du clonage, maintenant nous pouvons regarder autour de nous.
De plus, vous pouvez voir quelles modifications ont été apportées. D’ailleurs, le conflit y a été résolu. IDEA le montre également parfaitement. Si vous double-cliquez sur le fichier qui a été modifié lors de ce commit, nous verrons comment le conflit a été résolu : 
on remarque qu'à droite et à gauche il y avait deux versions du même fichier qui devaient être fusionnées en une seule. Et au milieu se trouve le résultat final. Lorsqu'un projet comporte de nombreuses branches, commits et utilisateurs qui travaillent dans le projet, vous devez effectuer une recherche séparément par branche (branche), utilisateur (utilisateur) et date (date) : 
Et la dernière chose que je veux expliquer avant de commencer est de savoir comment comprendre dans quelle branche nous sommes. Je vais vous donner une minute pour chercher... l'avez-vous trouvé ? Est-ce que vous abandonnez ? :D Dans le coin inférieur droit, il y a un bouton Git: master , où après Git: il indique sur quelle branche se trouve actuellement le projet. Si vous cliquez sur le bouton, vous pouvez faire beaucoup de choses utiles : passer à une autre branche, en créer une nouvelle, renommer une branche existante, etc. 
En conséquence, vous pouvez voir comment le README a changé, c'est-à-dire les modifications du référentiel distant ont été extraites et dans le coin inférieur droit, vous pouvez voir tous les détails des modifications provenant du serveur. 
les modifications sont terminées, vous pouvez maintenant créer un commit. Appuyez sur le raccourci clavier ctrl + k , nous obtenons : 
Avant de créer un commit, vous devez regarder attentivement ce qui est proposé dans cette fenêtre. J'ai spécifiquement ajouté une flèche pour vous montrer où chercher. Il y a beaucoup de choses intéressantes là-bas. Dans la section Commit Message , nous écrivons le texte du commit, et pour qu'il soit créé, vous devez cliquer sur le bouton Commit . Je n'ai toujours pas trouvé comment faire cela avec un raccourci clavier, donc si quelqu'un le trouve, écrivez, je serai très heureux. Nous écrivons que le README a changé et créons un commit. En conséquence, une alerte apparaîtra dans le coin inférieur gauche avec le nom du commit : 
Dans la branche master, appuyez sur ctrl + t pour obtenir ses dernières modifications depuis le serveur distant. Si vous regardez les modifications apportées, vous pouvez facilement remarquer ce qui s'est passé : 
comme vous pouvez le voir, le mot « complètement » a été supprimé. Peut-être que c’est quelqu’un du marketing qui a décidé que cela ne pouvait pas être écrit ainsi et a confié aux développeurs la tâche de le mettre à jour. Nous disposons désormais localement de la dernière version de la branche master. Revenons à readme-improver . Nous devons maintenant rebaser les modifications de la branche master vers la nôtre. Nous le faisons : 
Si vous avez tout suivi correctement avec moi, le résultat devrait être un conflit dans le fichier README : 
Il y a aussi ici beaucoup d'informations qui doivent être comprises et absorbées. Cela affiche une liste (dans notre cas d'un élément) des fichiers qui ont des conflits. Nous pouvons choisir trois options :
Ici, vous pouvez voir qu'il y a trois parties :
C'est ainsi que nous avons résolu notre premier conflit via Intellij IDEA :D
À gauche, il y aura une liste des commits qui n'ont pas été poussés vers le référentiel distant, et à droite, il y aura tous les fichiers qui ont été modifié. C'est tout : cliquez sur Push , et vous serez heureux :) Si le push réussit, il y aura une notification comme celle-ci dans le coin inférieur droit : 
cliquez sur Compare & pull request , puis cliquez sur Create pull request . Grâce au fait que nous avons résolu les conflits à l'avance, lors de la création d'une pull request, vous pouvez désormais la fusionner immédiatement : 
c'est tout ce que je voulais vous dire cette fois. Bien sûr, je viens d'ouvrir la porte et de vous en montrer une petite partie. Vous trouverez le reste vous-même selon vos besoins. Comme d'habitude, je vous invite à vous abonner à mon compte GitHub , où je publie des projets basés sur diverses technologies que j'utilise au travail. J'ai récemment eu une réalisation personnelle : mon projet a déjà été évalué par plus d'une centaine de développeurs. C'est un sentiment de joie incroyable que quelqu'un utilise ce que vous avez créé. Et l'utilise pour de bon.
GO TO FULL VERSION