Fidèle à la tradition établie, je vous salue en tant que futurs ingénieurs logiciels seniors. L'article d'aujourd'hui est le prolongement logique de mon article sur Git . Dans l'article sur Git, j'ai décrit comment travailler avec Git en ligne de commande. Aujourd'hui, je vais vous montrer comment tout faire dans IntelliJ IDEA. Au début de mon parcours en tant que développeur, j'utilisais la ligne de commande et je pensais que je n'avais pas besoin d'une interface graphique pour cela. Après tout, tout était clair comme ça... Mais c'était jusqu'au moment où j'ai commencé à utiliser Git dans IntelliJ IDEA... D'emblée, je tiens à dire que je décris mon expérience personnelle. Il existe plusieurs façons de résoudre un problème donné dans IntelliJ IDEA. Si vous connaissez un meilleur moyen que ce que je vais décrire dans l'article, écrivez-le dans les commentaires et nous en discuterons.
Entrées requises :
Lisez, suivez et comprenez mon article sur Git . Cela aidera à s'assurer que tout est configuré et prêt à fonctionner.
Installez IntelliJ IDEA.
Allouez une heure de temps personnel pour atteindre une maîtrise complète.
Travaillons avec 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 GitHub sera disponible et certaines icônes ne seront pas là où elles sont affichées dans l'article. Ne vous inquiétez pas : il vous suffit de ne pas passer à la nouvelle interface utilisateur ou de les 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 bifurquer le projet et de cloner votre propre copie.
Cloner mon référentiel et tout faire localement sans pouvoir tout pousser sur le serveur. Après tout, c'est mon référentiel :)
Pour cloner un projet depuis GitHub, vous devez copier le lien du projet et le transmettre à IntelliJ IDEA :
Copiez l'adresse du projet :
Ouvrez IntelliJ IDEA et sélectionnez "Get from Version Control":
Copiez et collez l'adresse du projet :
Vous serez invité à créer un projet IntelliJ IDEA. Acceptez l'offre :
Puisqu'il n'y a pas de système de construction et que cela dépasse le cadre de cet article, nous sélectionnons Créer un projet à partir de sources existantes :
Ensuite, vous verrez ce magnifique écran : Maintenant que nous avons compris le clonage, vous pouvez jeter un coup d'œil.
Premier aperçu d'IntelliJ IDEA en tant qu'interface utilisateur Git
Examinez de plus près le projet cloné : vous pouvez déjà obtenir de nombreuses informations sur le système de contrôle de version. Tout d'abord, nous avons le volet Version Control dans le coin inférieur gauche. Ici, vous pouvez trouver toutes les modifications locales et obtenir une liste des commits (analogue à "git log"). Passons à une discussion sur Log . Il existe une certaine visualisation qui nous aide à comprendre exactement comment le développement s'est déroulé. Par exemple, vous pouvez voir qu'une nouvelle branche a été créée avec un en-tête ajouté au commit txt , qui a ensuite été fusionné dans la branche principale. Si vous cliquez sur un commit, vous pouvez voir dans le coin droit toutes les informations sur le commit : toutes ses modifications et métadonnées.De plus, vous pouvez voir les changements réels. On voit aussi qu'un conflit s'y est résolu. IDEA le présente également très bien. Si vous double-cliquez sur le fichier qui a été modifié lors de ce commit, nous verrons comment le conflit a été résolu : Nous remarquons qu'à gauche et à droite nous avons les deux versions d'un même fichier qu'il fallait fusionner en une seule. Et au milieu, nous avons le résultat final fusionné. Lorsqu'un projet comporte de nombreuses branches, commits et utilisateurs, vous devez rechercher séparément par branche, utilisateur et date : la dernière chose que je veux expliquer avant de commencer est de savoir dans quelle branche nous nous trouvons. Je vais vous donner une minute pour le comprendre... L'avez-vous trouvé ? Abandonner? :D Dans le coin inférieur droit, il y a un bouton intitulé Git: master. Tout ce qui suit "Git :" est la branche actuelle. Si vous cliquez sur le bouton, vous pouvez faire beaucoup de choses utiles : basculer vers une autre branche, en créer une nouvelle, renommer une existante, etc.
Travailler avec un référentiel
Raccourcis clavier utiles
Pour les travaux futurs, vous devez vous souvenir de quelques raccourcis clavier très utiles :
CTRL+T — Récupère les dernières modifications depuis le référentiel distant (git pull).
CTRL+K — Créer un commit / voir toutes les modifications en cours. Cela inclut à la fois les fichiers non suivis et modifiés (voir mon article sur git, qui explique cela) (git commit).
CTRL+SHIFT+K — Il s'agit de la commande permettant de pousser les modifications vers le référentiel distant. Tous les commits créés localement et pas encore dans le dépôt distant seront poussés (git push).
ALT+CTRL+Z — Restauration des modifications d'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 faire le travail, nous devons maîtriser un scénario de base qui est utilisé partout. L'objectif est d'implémenter une nouvelle fonctionnalité dans une branche distincte, puis de la transférer vers un référentiel distant (vous devez également créer une demande d'extraction vers la branche principale, mais cela dépasse le cadre de cet article). Que faut-il pour faire cela ?
Obtenez toutes les modifications actuelles dans la branche principale (par exemple, "master").
À partir de cette branche principale, créez une branche distincte pour votre travail.
Implémenter la nouvelle fonctionnalité.
Allez à la branche principale et vérifiez s'il y a eu de nouveaux changements pendant que nous travaillions. Si non, alors tout va bien. Mais s'il y a eu des modifications, nous procédons comme suit : accédez à la branche de travail et rebasez les modifications de la branche principale sur la nôtre. Si tout se passe bien, tant mieux. Mais il est tout à fait possible qu'il y ait des conflits. En l'occurrence, ils peuvent simplement être résolus à l'avance, sans perdre de temps dans le référentiel distant.
Vous vous demandez pourquoi vous devriez faire cela ? C'est une bonne manière et empêche les conflits de se produire après avoir poussé votre branche vers le référentiel local (il y a, bien sûr, une possibilité que des conflits se produisent encore, mais cela devient beaucoup plus petit ).
Poussez vos modifications vers le référentiel distant.
La suite dépend de vos tâches et de votre imagination.
Obtenir les modifications du serveur distant ?
J'ai ajouté une description au README avec un nouveau commit et je souhaite obtenir ces modifications. Si des modifications ont été apportées à la fois dans le dépôt local et dans le dépôt distant, alors nous sommes invités à choisir entre une fusion et un rebase. Nous choisissons de fusionner. Entrez CTRL + T : Vous pouvez maintenant voir comment le README a changé, c'est-à-dire que 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 + Nouvelle branche .
Laissez la case Checkout branch cochée et saisissez le nom de la nouvelle succursale. Pour moi, ce sera readme-improver .
Git: master deviendra alors Git: readme-improver .
Simulons le travail en parallèle
Pour que des conflits apparaissent, quelqu'un doit les créer :D J'éditerai le README avec un nouveau commit via le navigateur, simulant ainsi un travail parallèle. C'est comme si quelqu'un apportait des modifications au même fichier pendant que je travaillais dessus. Le résultat sera un conflit. Je supprimerai le mot "fully" de la ligne 10.
Implémenter nos fonctionnalités
Notre tâche consiste à modifier le README et à ajouter une description au nouvel article. Autrement dit, le travail dans Git passe par IntelliJ IDEA. Ajoutez ceci : les modifications sont effectuées. Nous pouvons maintenant créer un commit. Appuyez sur CTRL+K , ce qui nous donne : Avant de créer un commit, nous devons regarder de près ce que propose cette fenêtre. J'ai ajouté des flèches rouges pour vous montrer où chercher. Il y a beaucoup de choses intéressantes ici. Dans la section Commit Message , nous écrivons le texte associé au commit. Ensuite, pour le créer, nous devons cliquer sur Commit. Je n'ai toujours pas trouvé comment faire cela avec un raccourci clavier. Si quelqu'un trouve comment, écrivez-moi, cela me ferait très plaisir. Nous écrivons que le README a changé et créons le commit. Une alerte apparaît dans le coin inférieur gauche avec le nom du commit :
Vérifier si la branche principale a changé
Nous avons terminé notre tâche. Ça marche. Nous avons écrit des tests. Tout va bien. Mais avant de pousser sur le serveur, nous devons encore vérifier s'il y a eu des changements dans la branche principale entre-temps. Comment cela a-t-il pu arriver ? Assez facilement : quelqu'un reçoit une tâche après vous, et que quelqu'un la termine plus rapidement que vous ne terminez votre tâche. Nous devons donc nous rendre dans la branche master. Pour ce faire, nous devons faire ce qui est affiché dans le coin inférieur droit de la capture d'écran ci-dessous : Dans la branche principale, appuyez sur CTRL+T pour obtenir ses dernières modifications depuis le serveur distant. En regardant les changements, vous pouvez facilement voir ce qui s'est passé :Le mot "fully" a été supprimé. Peut-être que quelqu'un du marketing a décidé qu'il ne devrait pas être écrit comme ça et a donné aux développeurs la tâche de le mettre à jour. Nous avons maintenant une copie locale de la dernière version de la branche master. Revenez au fichier readme-improver . Nous devons maintenant rebaser les modifications de la branche master vers la nôtre. Nous faisons ceci : Si vous avez tout fait correctement et suivi avec moi, le résultat devrait montrer un conflit dans le fichier README : Ici, nous avons également beaucoup d'informations à comprendre et à absorber. Voici une liste de fichiers (dans notre cas, un fichier) qui ont des conflits. Nous pouvons choisir parmi trois options :
acceptez le vôtre - n'acceptez que les modifications du fichier readme-improver.
accepter les leurs — n'accepter que les modifications du maître.
fusionner - choisissez vous-même ce que vous voulez garder et ce que vous voulez jeter.
Ce qui a changé n'est pas clair. S'il y a des changements dans la branche master, ils doivent y être nécessaires, nous ne pouvons donc pas simplement accepter nos changements. En conséquence, nous sélectionnons merge : Ici, nous pouvons voir qu'il y a trois parties :
Ce sont les changements de readme-improver.
Le résultat fusionné. Pour l'instant, c'est ce qui existait avant les changements.
Les changements de la branche master.
Nous devons produire un résultat fusionné qui satisfera tout le monde. En examinant ce qui a été modifié AVANT nos modifications, nous nous rendons compte qu'ils ont simplement supprimé le mot "fully". D'accord pas de problème! Cela signifie que nous allons également le supprimer dans le résultat fusionné, puis ajouter nos modifications. Une fois que nous avons corrigé le résultat fusionné, nous pouvons cliquer sur Appliquer . Ensuite, une notification apparaîtra, nous indiquant que le rebase a réussi : Voilà ! Nous avons résolu notre premier conflit grâce à IntelliJ IDEA :D
Pousser les modifications vers le serveur distant
L'étape suivante consiste à envoyer les modifications au serveur distant et à créer une demande d'extraction. Pour ce faire, appuyez simplement sur CTRL+SHIFT+K . Ensuite, nous obtenons : Sur la gauche, il y aura une liste des commits qui n'ont pas été poussés vers le référentiel distant. Sur la droite seront tous les fichiers qui ont changé. Et c'est tout! Appuyez sur Push et vous ferez l'expérience du bonheur :) Si le push réussit, vous verrez une notification comme celle-ci dans le coin inférieur droit :
Partie bonus
Au début, je ne voulais pas ajouter la création d'une pull request à cet article, mais ce n'est pas tout à fait complet sans cela. Alors, allons dans un dépôt GitHub (un qui est le vôtre, bien sûr :)) et on voit que GitHub sait déjà ce qu'on veut : Cliquez sur Compare & pull request . Cliquez ensuite sur Créer une demande d'extraction . Parce que nous avons résolu les conflits à l'avance, maintenant lors de la création d'une pull request, nous pouvons immédiatement la fusionner : Et c'est tout ce que je voulais dire cette fois. Bien sûr, je ne vous ai ouvert qu'un peu la porte et vous ai montré une petite partie. Vous apprendrez le reste au fur et à mesure de vos besoins. J'ai l'habitude de vous inviter à me suivre sur GitHub, où je poste mes projets impliquant diverses technologies que j'utilise au travail. J'ai récemment fait un exploit personnel : un de mes projets a été étoilé par plus d'une centaine de développeurs. Il y a un sentiment de joie incroyable quand vous savez que ce que vous avez fait est utilisé par quelqu'un d'autre. Et l'utiliser pour de bon.
L'article d'aujourd'hui est le prolongement logique de mon article sur Git . Dans l'article sur Git, j'ai décrit comment travailler avec Git en ligne de commande. Aujourd'hui, je vais vous montrer comment tout faire dans IntelliJ IDEA. Au début de mon parcours en tant que développeur, j'utilisais la ligne de commande et je pensais que je n'avais pas besoin d'une interface graphique pour cela. Après tout, tout était clair comme ça... Mais c'était jusqu'au moment où j'ai commencé à utiliser Git dans IntelliJ IDEA... D'emblée, je tiens à dire que je décris mon expérience personnelle. Il existe plusieurs façons de résoudre un problème donné dans IntelliJ IDEA. Si vous connaissez un meilleur moyen que ce que je vais décrire dans l'article, écrivez-le dans les commentaires et nous en discuterons.
Maintenant que nous avons compris le clonage, vous pouvez jeter un coup d'œil.
De plus, vous pouvez voir les changements réels. On voit aussi qu'un conflit s'y est résolu. IDEA le présente également très bien. Si vous double-cliquez sur le fichier qui a été modifié lors de ce commit, nous verrons comment le conflit a été résolu : Nous remarquons 
qu'à gauche et à droite nous avons les deux versions d'un même fichier qu'il fallait fusionner en une seule. Et au milieu, nous avons le résultat final fusionné. Lorsqu'un projet comporte de nombreuses branches, commits et utilisateurs, vous devez rechercher séparément par branche, utilisateur et date : 
la dernière chose que je veux expliquer avant de commencer est de savoir dans quelle branche nous nous trouvons. Je vais vous donner une minute pour le comprendre... L'avez-vous trouvé ? Abandonner? :D Dans le coin inférieur droit, il y a un bouton intitulé Git: master. Tout ce qui suit "Git :" est la branche actuelle. Si vous cliquez sur le bouton, vous pouvez faire beaucoup de choses utiles : basculer vers une autre branche, en créer une nouvelle, renommer une existante, etc.
Vous pouvez maintenant voir comment le README a changé, c'est-à-dire que 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 effectuées. Nous pouvons maintenant créer un commit. Appuyez sur CTRL+K , ce qui nous donne : 
Avant de créer un commit, nous devons regarder de près ce que propose cette fenêtre. J'ai ajouté des flèches rouges pour vous montrer où chercher. Il y a beaucoup de choses intéressantes ici. Dans la section Commit Message , nous écrivons le texte associé au commit. Ensuite, pour le créer, nous devons cliquer sur Commit. Je n'ai toujours pas trouvé comment faire cela avec un raccourci clavier. Si quelqu'un trouve comment, écrivez-moi, cela me ferait très plaisir. Nous écrivons que le README a changé et créons le commit. Une alerte apparaît dans le coin inférieur gauche avec le nom du commit :
Dans la branche principale, appuyez sur CTRL+T pour obtenir ses dernières modifications depuis le serveur distant. En regardant les changements, vous pouvez facilement voir ce qui s'est passé :
Le mot "fully" a été supprimé. Peut-être que quelqu'un du marketing a décidé qu'il ne devrait pas être écrit comme ça et a donné aux développeurs la tâche de le mettre à jour. Nous avons maintenant une copie locale de la dernière version de la branche master. Revenez au fichier readme-improver . Nous devons maintenant rebaser les modifications de la branche master vers la nôtre. Nous faisons ceci : 
Si vous avez tout fait correctement et suivi avec moi, le résultat devrait montrer un conflit dans le fichier README : 
Ici, nous avons également beaucoup d'informations à comprendre et à absorber. Voici une liste de fichiers (dans notre cas, un fichier) qui ont des conflits. Nous pouvons choisir parmi trois options :
Ici, nous pouvons voir qu'il y a trois parties :
Voilà ! Nous avons résolu notre premier conflit grâce à IntelliJ IDEA :D
Sur la gauche, il y aura une liste des commits qui n'ont pas été poussés vers le référentiel distant. Sur la droite seront tous les fichiers qui ont changé. Et c'est tout! Appuyez sur Push et vous ferez l'expérience du bonheur :) Si le push réussit, vous verrez une notification comme celle-ci dans le coin inférieur droit :
Cliquez sur Compare & pull request . Cliquez ensuite sur Créer une demande d'extraction . Parce que nous avons résolu les conflits à l'avance, maintenant lors de la création d'une pull request, nous pouvons immédiatement la fusionner : 
Et c'est tout ce que je voulais dire cette fois. Bien sûr, je ne vous ai ouvert qu'un peu la porte et vous ai montré une petite partie. Vous apprendrez le reste au fur et à mesure de vos besoins. J'ai l'habitude de vous inviter à me suivre sur GitHub, où je poste mes projets impliquant diverses technologies que j'utilise au travail. J'ai récemment fait un exploit personnel : un de mes projets a été étoilé par plus d'une centaine de développeurs. Il y a un sentiment de joie incroyable quand vous savez que ce que vous avez fait est utilisé par quelqu'un d'autre. Et l'utiliser pour de bon.