Il est naturel que les gens résistent au changement. Si vous n'avez pas découvert Git lorsque vous avez commencé à travailler avec des systèmes de contrôle de version, vous vous sentez probablement plus à l'aise avec Subversion (SVN).

On dit souvent que Git est trop difficile pour les débutants. Cependant, je ne suis pas d’accord sur ce point.

Dans ce tutoriel, je vais vous montrer comment utiliser Git dans vos projets. Disons que vous créez un projet à partir de zéro et que vous souhaitez le gérer à l'aide de Git. Parcourir la liste des commandes de base vous donnera une idée de la façon d'héberger votre code dans le cloud à l'aide de GitHub.

Dans cet article, nous parlerons des bases de Git : comment initialiser vos projets, comment gérer les fichiers nouveaux et existants et comment stocker votre code dans le cloud.

Nous n'aborderons pas les parties relativement complexes de Git, comme le branchement, puisque ce tutoriel est destiné aux débutants.

Installer Git

Sur le site officiel de Git, il y a des informations détaillées sur son installation sur Linux, Mac et Windows. Dans notre cas, nous utiliserons Ubuntu 13.04 à des fins de démonstration, où nous installerons Git en utilisant apt-get :

sudo apt-get install git

La configuration initiale

Créons un répertoire dans lequel nous travaillerons. Alternativement, vous pouvez utiliser Git pour gérer l'un de vos projets existants ; dans ce cas, vous n'aurez pas besoin de créer un répertoire de démonstration comme ci-dessous :

mkdir mon_git_project cd mon_git_project

La première étape consiste à initialiser Git dans le répertoire. Cela peut être fait à l'aide de la commande init, qui crée un répertoire .git contenant toutes les informations relatives à Git pour votre projet.

git config --global user.name "Shaumik" git config --global user.email " [email protégé]" git config --global color.ui "auto"

Il est important de noter que si vous ne fournissez pas votre nom et votre adresse email, les valeurs par défaut seront utilisées. Dans notre cas, les valeurs par défaut seraient le nom d'utilisateur donny et l'adresse email donny@ubuntu.

Nous définissons également la couleur de l'interface utilisateur sur auto , ce qui rendra la sortie des commandes Git codée par couleur.

Le préfixe --global avant les commandes permet d'éviter d'avoir à saisir ces commandes de configuration la prochaine fois que nous exécuterons un projet Git sur notre système.

Préparation des fichiers pour la validation

L'étape suivante consiste à créer les fichiers dans le répertoire. Vous pouvez utiliser, par exemple, l'éditeur de texte Vim. Notez que si vous souhaitez ajouter Git à un répertoire déjà existant, vous n'avez pas besoin de suivre cette étape :

Vérifier l'état du référentiel

Maintenant que nous avons quelques fichiers dans notre référentiel, voyons comment Git les gère. Afin de vérifier l'état actuel du référentiel, vous devez utiliser la commande git status :

Ajout de fichiers à Git pour le suivi

Nous n'avons aucun fichier à suivre avec Git pour le moment. Nous devons ajouter des fichiers spécifiquement à Git afin d'indiquer à Git quoi suivre.

Ajoutez des fichiers à l'aide de la commande add :

En vérifiant à nouveau l'état du référentiel, nous pouvons voir qu'un fichier a été ajouté :

Pour ajouter plusieurs fichiers, vous pouvez utiliser l'entrée de commande suivante (notez que nous avons ajouté un fichier supplémentaire à des fins de démonstration) :

git add monfichier2 monfichier3

Vous pouvez utiliser git add de manière récursive, mais soyez prudent avec cette commande. Certains fichiers (tels que les fichiers compilés) sont généralement stockés en dehors d'un référentiel Git.

Si vous utilisez la commande add de manière récursive, elle ajoutera tous ces fichiers s'ils existent dans votre référentiel.

Suppression de fichiers

Mais exécuter une simple commande git rm supprimera non seulement le fichier de Git, mais également de votre système de fichiers local ! À

Git a cessé de suivre le fichier, mais le fichier lui-même reste sur votre système local, exécutez la commande suivante :

git rm --cached

Valider les modifications

Une fois que vous avez hébergé vos fichiers, vous pouvez les valider sur Git. Considérez un commit comme la capture d'un moment spécifique auquel vous pouvez revenir pour accéder à votre référentiel à ce stade.

Vous pouvez joindre un message à chaque commit, qui est ajouté en utilisant le préfixe -m :

git commit -m "Mon premier commit"

Donnez à vos commits des messages utiles car cela vous aidera à identifier ce que vous avez modifié dans ce commit.

Évitez les messages trop généraux comme " Bugs corrigés" Si vous disposez d'un outil de suivi des tâches, vous pouvez ajouter des messages tels que " Correction du bug n°234».

Il est recommandé d'utiliser le nom de la branche ou le nom de la fonctionnalité comme préfixe du message de validation. Par exemple, " Gestion des actifs : fonction ajoutée pour générer des fichiers PDF des actifs» est un message significatif.

Git identifie les commits en ajoutant un long nombre hexadécimal à chaque commit. En règle générale, vous n'avez pas besoin de copier la ligne entière : les 5 à 6 premiers caractères suffisent pour identifier votre commit.

Notez que dans la capture d'écran, notre premier commit est défini par le code 8dd76fc.

D'autres engagements

Modifions maintenant quelques fichiers après notre premier commit. Après les avoir modifiés, nous verrons qu'à la suite de l'exécution de la commande git status, Git a détecté des changements dans les fichiers qu'il surveille :

Vous pouvez vérifier les modifications apportées aux fichiers suivis lors de la dernière validation à l'aide de la commande git diff. Si vous souhaitez afficher les modifications apportées à un fichier spécifique, utilisez la commande git diff :

Vous devez ajouter à nouveau ces fichiers pour apporter des modifications aux fichiers suivis pour la prochaine validation. Vous pouvez ajouter tous les fichiers suivis en exécutant la commande :

Vous pouvez éviter d'utiliser cette commande en utilisant le préfixe -a à la commande git commit, qui ajoutera toutes les modifications aux fichiers suivis.

Ce processus est cependant très dangereux car il peut nuire au projet. Par exemple, disons que vous ouvrez un fichier et que vous le modifiez par erreur.

Si vous placez des fichiers de manière sélective, vous remarquerez des changements dans chaque fichier. Mais si vous préfixez -a à votre commit, tous les fichiers seront validés et vous ne pourrez pas détecter d'éventuelles erreurs.

Une fois que vous avez placé vos fichiers, vous pouvez commencer à les valider. J'ai mentionné que chaque commit peut être associé à un message, que nous saisissons en utilisant le préfixe -m.

Il est cependant possible de saisir un message sur plusieurs lignes à l'aide de la commande git commit, qui ouvre un formulaire d'écriture interactif :

Gestion de projet

Pour afficher l'historique de votre projet, vous pouvez exécuter la commande suivante :

Cela affichera l'historique complet du projet, qui est une liste de tous les commits et des informations les concernant. Les informations de validation incluent le hachage de validation, l'auteur, l'heure et le message de validation. Il existe différentes options pour git log que vous pouvez explorer une fois que vous maîtrisez le concept de branche dans Git.

Pour afficher des informations détaillées sur une validation spécifique et les fichiers modifiés, exécutez la commande suivante :

spectacle git

Où il s'agit du nombre hexadécimal associé au commit. Ce tutoriel étant destiné aux débutants, nous n'expliquerons pas comment revenir à l'état d'un commit spécifique ni comment gérer les branches.

Hébergement du code dans le cloud

Maintenant que vous avez appris à gérer le code sur votre système, il est temps d'héberger le code dans le cloud.

Les systèmes de contrôle de version distribués (DVCS) remplacent progressivement les systèmes centralisés. Si vous n’en avez pas encore utilisé, c’est le moment d’essayer.

Dans cet article, je vais essayer de montrer comment vous pouvez rapidement commencer à expérimenter avec git en utilisant le site Web github.com.

Cet article ne discutera pas des différences entre les différents DVCS. De plus, travailler avec git ne sera pas abordé en détail ; il existe de nombreuses bonnes sources sur ce sujet, que je fournirai à la fin de l'article.

Ainsi, le site github.com se positionne comme un service d'hébergement de projets web utilisant le système de contrôle de version git, ainsi qu'un réseau social pour les développeurs. Les utilisateurs peuvent créer un nombre illimité de référentiels, chacun étant doté d'un wiki, d'un système de suivi des problèmes, de la possibilité d'effectuer des révisions de code et bien plus encore. GitHub est actuellement le service de ce type le plus populaire, devant Sourceforge et Google Code.

Pour les projets open source, l'utilisation du site est gratuite. Si vous avez besoin de dépôts privés, vous pouvez passer à un forfait payant :

Commençons par l'inscription. Suivez le lien github.com/signup/free et entrez vos données.
Après inscription, nous sommes redirigés vers le Dashboard de notre compte :

Désormais, nous n'avons plus de référentiel unique et nous pouvons soit créer un nouveau référentiel, soit partir du référentiel existant de quelqu'un d'autre et diriger notre propre branche de développement. Ensuite, si vous le souhaitez, vous pourrez proposer vos modifications à l'auteur du dépôt d'origine (Pull request).

Mais d'abord, installons git et configurons-le pour qu'il fonctionne avec le site.

Si vous travaillez sous Windows, téléchargez et installez msysgit. Il s'agit de la version console de git pour Windows (plus loin l'histoire sera basée sur l'exemple de ce système d'exploitation).
Instructions pour MacOS X (eng)
Instructions pour Linux (eng)
Il ne devrait y avoir aucun problème, cliquez simplement sur Suivant partout. Après l'installation, sélectionnez dans le menu contextuel de Git Bash Explorer :

Ou via Git Bash.lnk dans le dossier avec le programme installé :

Nous entrons nos paramètres de données et de saut de ligne dans la console :
git config --global user.name "votre nom"
git config --global user.email "votre email"
git config --global core.autocrlf vrai
git config --global core.safecrlf vrai

À propos, je recommande de suivre un bon cours interactif sur l'utilisation de git depuis la console. Le cours se déroule en quelques heures et fournit les compétences de base nécessaires.

Pour ceux qui préfèrent l'interface graphique, il existe plusieurs outils de ce type pour travailler avec git sous Windows. Les deux principaux sont SmartGit (multiplateforme) et TortoiseGit. Les deux sont bons et celui à utiliser est une question de goût. Je vais décrire le travail avec TortoiseGit.
Pour les coquelicots, il existe également un choix de giu.

• Le client officiel de GitHub est encore assez rudimentaire à mon avis.
• GitX - Personnellement, je ne l'ai pas aimé
• GitBox - la plupart suivent la méthode Mac, je recommande fortement de l'essayer

À propos de git en russe :
"Un modèle de branchement réussi pour git" - traduction d'un bon article en anglais
Cours interactif githowto.com sur l'utilisation de git depuis la console
"Pourquoi git" + discussion
"Git pour ceux qui migrent depuis SVN" + discussion

Une introduction détaillée au travail avec Git

Qu’est-ce que Git et pourquoi en ai-je besoin ?

Git est un système de contrôle de version distribué qui vous permet d'enregistrer toutes les modifications apportées aux fichiers stockés dans un référentiel. Les modifications sont stockées dans des instantanés appelés commits, qui peuvent être partagés sur plusieurs serveurs. Considérez-le comme une sauvegarde cloud standard sous stéroïdes : non seulement vous pouvez restaurer votre code en cas de panne, mais vous pouvez également restaurer votre code à l'un des états enregistrés précédents. Vous pouvez également facilement collaborer avec d'autres développeurs. Là encore, tout comme plusieurs personnes peuvent travailler sur le même fichier dans Google Docs, les développeurs peuvent travailler sur le même référentiel en même temps et enregistrer leurs modifications.

De par tous ses avantages, Git est un outil indispensable pour quiconque s’engage ou a l’intention de s’engager dans le développement. Dans cet article, nous examinerons les commandes Git les plus utiles et quand les utiliser. Cela vous aidera également à rafraîchir vos connaissances si vous êtes déjà familier avec Git.

Comment travailler avec Git

Il existe de nombreuses commandes disponibles dans Git, il est donc utile de les répartir par sujet/raison d'utilisation. Nous examinerons d'abord comment travailler avec Git sur une machine locale, puisque la plupart du travail s'y déroule, puis nous passerons au format multi-utilisateurs.

Vous pouvez travailler avec Git via la ligne de commande ou via une interface graphique comme GitHub Desktop. Bien que la ligne de commande puisse être intimidante pour les nouveaux développeurs, elle vaut toujours la peine d'être apprise car elle offre plus d'options que de nombreux outils frontaux.

Généralement, les commandes Git prennent la forme git<команда> <аргументы>, où l'argument peut être un chemin de fichier. Les commandes peuvent également avoir des options, notées --<опция>ou -<однобуквенная опция>. Ils permettent de personnaliser plus en détail les actions de l'équipe. Dans cet article, les commandes seront présentées sous une forme générale, donc tout ce qui est dans<>, vous devrez le remplacer par vos propres valeurs.

Si vous ne savez pas comment utiliser la commande, vous pouvez ouvrir le manuel en utilisant git help<команда>et si vous avez juste besoin d'un rappel, utilisez git<команда>-h ou git<команда>--help (--help et -h sont équivalents).

Préparation de Git

Installer Git

Les utilisateurs Windows peuvent le télécharger ici.

Sur macOS (OS X), Git fait partie des outils de ligne de commande XCode, vous devez donc les installer. Pour rechercher Git, ouvrez un terminal et tapez git --version pour vérifier la version.

Si vous utilisez Linux, utilisez la commande sudo apt install git-all (distributions basées sur Debian) ou sudo dnf install git-all (basée sur RPM).

Mise en place d'un fichier de configuration

La première chose à faire après avoir installé Git est de configurer un nom d'utilisateur et une adresse e-mail, car ceux-ci sont utilisés pour l'identification et sont stockés dans tous les instantanés que vous prenez. Ces paramètres, ainsi que tous les autres, sont stockés dans le fichier de configuration.

Vous pouvez soit modifier directement le fichier .gitconfig à l'aide d'un éditeur de texte, soit à l'aide de la commande git config --global --edit, et vous pouvez également modifier des champs individuels à l'aide de la commande git config --global<поле> <значение>- nous nous intéressons aux champs user.name et user.email.

Vous pouvez également configurer un éditeur de texte pour rédiger des messages de validation à l'aide du champ core.editor. Initialement, l'éditeur par défaut du système est utilisé, par exemple vi pour Linux/Mac. Le champ commit.template permet de spécifier le modèle qui sera utilisé pour chaque commit.

Il existe de nombreux autres champs, mais l'un des plus utiles est alias, qui associe une commande à un alias. Par exemple, git config --global alias.st "status -s" vous permet d'utiliser git st au lieu de git status -s

La commande git config --list listera tous les champs et leurs valeurs du fichier de configuration.

Créer un dépôt Git

Pour initialiser un nouveau dépôt .git, vous pouvez utiliser la commande git init ou, si vous souhaitez en copier un existant, git clone<адрес репозитория> .

Historique des commits Git

Git stocke les données sous la forme d'un ensemble d'instantanés légers appelés commits. Ils stockent l'état du système de fichiers à un moment donné, ainsi qu'un pointeur vers le(s) commit(s) précédent(s). Chaque commit contient une somme de contrôle unique – un identifiant que Git utilise pour référencer le commit. Pour garder une trace de l'historique, Git conserve un pointeur HEAD qui pointe vers le premier commit (nous suivons la chaîne de commits dans l'ordre inverse pour accéder aux commits précédents).

Nous pouvons faire référence à un commit soit par sa somme de contrôle, soit par sa position par rapport à HEAD, par exemple HEAD~4 fait référence à un commit qui a 4 commits avant HEAD.

Système de fichiers Git

Git suit les fichiers dans trois sections principales :

• répertoire de travail (le système de fichiers de votre ordinateur) ;
• zone de fichiers préparés (zone de préparation, stocke le contenu du prochain commit);
• HEAD (dernier commit dans le référentiel).

Toutes les commandes de base pour travailler avec des fichiers se résument à comprendre comment Git gère ces trois sections. Il existe une idée fausse répandue selon laquelle la zone de préparation ne stocke que les modifications. Il est préférable de considérer ces trois partitions comme des systèmes de fichiers distincts, chacun contenant ses propres copies des fichiers.

Afficher les modifications apportées aux systèmes de fichiers

La commande git status affiche tous les fichiers qui diffèrent entre les trois sections. Les fichiers ont 4 états :

1. Non suivi : situé dans le répertoire de travail, mais il n'y a pas de version dans le HEAD ou la zone de préparation (Git ne connaît pas le fichier).
2. Modifié - Il existe une version plus récente dans le répertoire de travail que celle stockée dans HEAD ou dans la zone de préparation (les modifications ne figurent pas dans la prochaine validation).
3. Préparé (préparé) - dans le répertoire de travail et la zone des fichiers préparés, il existe une version plus récente par rapport à celle stockée dans HEAD (prête à être validée).
4. Aucun changement - une version du fichier dans toutes les sections, c'est-à-dire que le dernier commit contient la version actuelle.

Remarque Un fichier peut être à la fois « modifié » et « préparé » si la version dans le répertoire de travail est plus récente que la version dans la zone des fichiers préparés, qui est plus récente que la version dans HEAD.

Nous pouvons utiliser l'option -s de la commande git status pour obtenir une sortie plus compacte (une ligne par fichier). Si le fichier n'est pas suivi, qu'est-ce qui sera affiché ? ; s'il a été modifié, son nom sera rouge, et s'il a été préparé, il sera vert.

Pour afficher les modifications elles-mêmes, et non les fichiers modifiés, vous pouvez utiliser les commandes suivantes :

• git diff - comparez le répertoire de travail avec la zone des fichiers préparés ;
• git diff --staged - compare la zone des fichiers préparés avec HEAD.

Si vous utilisez l'argument<файл/папка>, alors diff affichera les modifications uniquement pour les fichiers/dossiers spécifiés, par exemple git diff src/ .

Mise à jour des systèmes de fichiers

commande git add<файл/папка>met à jour la zone des fichiers préparés avec les versions des fichiers/dossiers du répertoire de travail.

La commande git commit met à jour HEAD avec un nouveau commit, qui prend des instantanés des fichiers dans la zone de transit.

Action de la commande git reset<коммит>se compose de trois étapes potentielles :

1. Déplacez le pointeur HEAD vers<коммит>(par exemple, lorsqu'une validation est annulée, le répertoire de travail et la zone de transit auront des versions de fichiers plus récentes que celles de HEAD). De plus, le pointeur HEAD de la branche sera déplacé vers ce commit.
2. Mettez à jour la zone de préparation avec le contenu du commit. Dans ce cas, seul le répertoire de travail disposera des dernières versions des fichiers.
3. Mettez à jour le répertoire de travail avec le contenu de la zone des fichiers préparés. Vous devez être prudent avec cela car cela finira par détruire les modifications de vos fichiers.

Par défaut, la commande git reset n'effectue que les étapes 1 et 2, mais son comportement peut être modifié à l'aide des options --soft (1 étape uniquement) et --hard (toutes les étapes).

Si vous transmettez le chemin d'un fichier/dossier, la commande sera exécutée uniquement pour eux, par exemple git reset --soft HEAD~1 src/ .

commande git checkout HEAD<файл>produit le même résultat que git reset --hard HEAD<файл>- écrase la version du fichier dans la zone des fichiers préparés et dans le répertoire de travail par la version de HEAD, c'est-à-dire qu'il annule les modifications après la dernière validation.

D'un autre côté, git checkout<файл>(sans HEAD) écrase la version du fichier dans le répertoire de travail par la version dans la zone des fichiers préparés, c'est-à-dire qu'il annule les modifications depuis la dernière version préparée.

Enfin, git rm<файл>détraque un fichier et le supprime du répertoire de travail, l'option --cached permettra de sauvegarder le fichier.

Ignorer les fichiers

Souvent, nous n'avons pas besoin de Git pour garder une trace de tous les fichiers d'un référentiel, car ceux-ci peuvent inclure :

• fichiers contenant des informations sensibles telles que des mots de passe ;
• gros fichiers binaires ;
• les fichiers d'assemblage générés après chaque compilation ;
• Fichiers spécifiques au système d'exploitation/IDE, par ex. .DS_Store pour macOS ou .iml pour IntelliJ IDEA - nous avons besoin que le référentiel dépende le moins possible du système.

Pour ignorer, le fichier .gitignore est utilisé. Pour marquer les fichiers que nous souhaitons ignorer, nous pouvons utiliser des modèles de recherche (considérez-les comme des expressions régulières simplifiées) :

• /___ - évite la récursivité - fait correspondre les fichiers uniquement dans le répertoire courant ;
• __/ - correspond à tous les fichiers du répertoire spécifié ;
• *___ - correspond à tous les fichiers avec la fin spécifiée ;
• ! - ignorer les fichiers qui correspondent au modèle spécifié ;
• [__] - correspond à n'importe quel caractère spécifié entre crochets ;
• ? - correspond à n'importe quel caractère ;
• /**/ - correspond aux sous-répertoires, par exemple a/**/d correspond à a/d , a/b/d , a/b/c/d , etc.

Nous pouvons même utiliser des modèles de recherche lors de la spécification d'un fichier/dossier dans d'autres commandes. Par exemple, git add src/*.css ajoutera tous les fichiers .css dans le dossier src.

S'engage

Puisque les commits constituent la base de l’historique des versions, c’est une bonne idée d’en apprendre un peu plus à leur sujet.

La commande git commit ouvrira un éditeur de texte pour que vous puissiez saisir votre message de validation. Cette commande accepte également plusieurs arguments courants :

• -m vous permet d'écrire un message avec la commande sans ouvrir l'éditeur. Par exemple git commit -m "Correction du bug" ;
• -a déplace tous les fichiers suivis vers la zone de préparation et les inclut dans la validation (vous permet d'ignorer git add avant la validation) ;
• --amend remplace le dernier commit par un nouveau commit modifié, ce qui peut être utile si vous avez mal orthographié le dernier message de commit ou si vous avez oublié d'y inclure certains fichiers.

Quelques conseils à prendre en compte :

• Engagez-vous souvent : vous ne pouvez pas annuler les modifications s'il n'y a rien sur quoi revenir.
• Un changement, un commit : ne regroupez pas toutes les modifications non liées dans un seul commit, séparez-les pour faciliter la restauration.
• Format du message : le titre doit être à l'impératif, comporter moins de 50 caractères et doit compléter logiquement la phrase ce commit ___ (ce commit corrigera les bugs - ce commit corrigera les bugs). Le message doit expliquer pourquoi la validation a été effectuée et la validation elle-même doit montrer ce qui a changé. décrit en détail comment écrire des messages de validation.
• (Facultatif) Ne validez pas de modifications mineures : dans un référentiel volumineux, de nombreuses petites validations peuvent encombrer l'historique. Il est considéré comme une bonne pratique d'effectuer de tels commits pendant le développement et, lors de leur ajout à un grand référentiel, de les combiner en un seul commit.

Afficher les modifications dans l'historique

Pour afficher l'historique des commits précédents dans l'ordre chronologique inverse, vous pouvez utiliser la commande git log. Vous pouvez lui passer différentes options :

• -p affiche les modifications dans chaque validation ;
• --stat affiche de courtes statistiques sur les commits, telles que les fichiers modifiés et le nombre de lignes ajoutées/supprimées dans chacun d'eux ;
• -n montre n derniers commits ;
• --since=___ et --until=___ vous permettent de filtrer les commits par période de temps, par exemple --since="2019-01-01" affichera les commits depuis le 1er janvier 2019 ;
• --pretty vous permet de spécifier le format du journal (par exemple, --pretty=oneline), vous pouvez également utiliser --pretty=format pour plus de personnalisation, par exemple --pretty=format:"%h %s" ;
• --grep et -S filtrent les validations avec les messages/modifications de code qui contiennent la ligne spécifiée, par exemple, git log -S function_name vous permet de voir l'ajout/la suppression d'une fonction ;
• --no-merges ignore les commits qui fusionnent les branches ;
• branch1..branch2 vous permet de voir quels commits de la branche 2 ne sont pas dans la branche 1 (utile lors de la fusion de branches). Par exemple, git log master..test montrera quels commits de la branche test ne sont pas dans master (nous parlerons des branches un peu plus tard).
• --left-right branch1...branch2 affiche les commits qui se trouvent soit dans la branche 1, soit dans la branche 2, mais pas dans les deux ; signe< обозначает коммиты из ветка1 , а >- de la branche 2. Attention : trois points sont utilisés, pas deux ;
• -L prend un argument start,end:file ou:function:file et affiche l'historique des modifications de l'ensemble de lignes ou de fonctions transmis dans le fichier.

Une autre commande utile est git blâme<файл>, qui, pour chaque ligne du fichier, affiche l'auteur et la somme de contrôle du dernier commit qui a modifié cette ligne. -L<начало>, <конец>vous permet de limiter cette commande aux chaînes spécifiées. Cela peut être utilisé, par exemple, pour découvrir quel commit a conduit à un certain bug (afin qu'il puisse être annulé).

Enfin, il existe la commande git grep, qui recherche tous les fichiers de l'historique des validations (pas seulement le répertoire de travail, comme grep) à l'aide d'une expression régulière donnée. L'option -n affiche le numéro de ligne correspondant dans le fichier pour chaque correspondance, et l'option --count affiche le nombre de correspondances pour chaque fichier.

Remarque Ne confondez pas git grep avec git log --grep ! Le premier recherche par fichiers parmi les validations et le second examine les messages du journal.

Serveurs distants

Jusqu’à présent, nous avons discuté de l’utilisation de Git uniquement sur la machine locale. Cependant, nous pouvons stocker un historique de validation de référentiels distants qui peuvent être suivis et mis à jour (considérez-les comme des sauvegardes cloud distantes de notre historique de validation).

La commande git remote -v répertorie les référentiels distants que nous surveillons et les noms que nous leur avons attribués.

Lors de l'utilisation de la commande git clone Nous téléchargeons non seulement une copie du référentiel, mais suivons également implicitement le serveur distant, qui se trouve à l'adresse spécifiée et qui est nommé origin.

Commandes les plus utilisées :

• git ajout à distance<имя> - ajoute un référentiel distant avec le nom donné ;
• git télécommande supprimer<имя>- supprime un référentiel distant portant un nom donné ;
• git renommer à distance<старое имя> <новое имя>- renomme le référentiel distant ;
• URL de configuration distante git<имя> - attribue une nouvelle adresse au référentiel avec le nom ;
• git show à distance<имя>- affiche des informations sur le référentiel.

Les commandes suivantes fonctionnent avec les branches distantes :

• git récupérer<имя> <ветка>- reçoit les données d'une branche d'un référentiel donné, mais ne fusionne pas les modifications ;
• git pull<имя> <ветка>- fusionne les données d'une branche d'un référentiel donné ;
• git pousser<имя> <ветка>- pousse les modifications vers une branche du référentiel spécifié. Si la branche locale suit déjà la branche distante, vous pouvez simplement utiliser git push ou git pull .

De cette façon, plusieurs personnes peuvent demander des modifications au serveur, apporter des modifications aux copies locales, puis les transférer vers un serveur distant, leur permettant ainsi d'interagir les unes avec les autres au sein du même référentiel.

Ramification

Tout cela est bien beau si chaque développeur travaille sur un projet à des moments différents. Les diagrammes présentés ci-dessus ne montraient que des situations dans lesquelles le référentiel d'origine ou la copie locale avait été modifié, et non le travail de plusieurs personnes.

Cela nous amène à une fonctionnalité clé de Git : le branchement, la possibilité de travailler sur différentes versions d'un projet. Cela signifie qu'au lieu d'avoir une liste de commits dans l'ordre, l'historique divergera à certains moments (le faisant ressembler à un arbre). Chaque branche de Git contient un pointeur HEAD léger vers le dernier commit de cette branche, vous permettant de créer plusieurs branches sans aucun effort supplémentaire. Astuce : Nommez la branche en fonction de la fonctionnalité qu'elle développe. La branche par défaut est appelée master.

Nous avons donc un pointeur général TÊTE et HEAD pour chaque branche. Donc, passer d'une branche à l'autre implique uniquement de déplacer TÊTE dans le HEAD de la branche correspondante.

Commandes standards :

• branche git<имя ветки>- crée une nouvelle branche avec HEAD pointant vers TÊTE. Si tu ne réussis pas un argument<имя ветки>, alors la commande listera toutes les branches locales ;
• git paiement<имя ветки>- passe à ce fil. Vous pouvez passer l'option -b pour créer une nouvelle branche avant de changer ;
• branche git -d<имя ветки>- supprime la branche.

Notre référentiel local et celui distant peuvent avoir plusieurs branches, donc lorsque vous suivez le référentiel distant, c'est en fait la branche distante que vous suivez (git clone relie votre branche principale à la branche origine/maître du référentiel distant).

Lien vers une branche distante :

• branche git -u<имя удалённого репозитория>/<удалённая ветка>- relie la branche actuelle à la branche distante spécifiée ;
• git checkout--track<имя удалённого репозитория>/<удалённая ветка>- analogue de la commande précédente ;
• git checkout-b<ветка> <имя удалённого репозитория>/<удалённая ветка>- crée une nouvelle branche locale et commence à suivre la branche distante ;
• git branch --vv - affiche les branches distantes locales et suivies ;
• git paiement<удалённая ветка>- crée une branche locale avec le même nom que la branche distante et commence à la surveiller.

En général, git checkout consiste à changer l'emplacement pointé par le HEAD de la branche, ce qui est similaire à la façon dont git reset déplace le HEAD partagé.

Cache-cache

Il y a une subtilité : lors du changement de branche, Git exige que l'état de fonctionnement soit propre, c'est-à-dire que toutes les modifications apportées aux fichiers suivis doivent être validées.

Note traduction Ce n'est pas tout à fait vrai. Dans certaines circonstances, Git peut automatiquement transmettre une modification non validée vers une autre branche.

Cependant, il arrive parfois que vous ayez des modifications inachevées qui ne peuvent pas être validées. Dans une telle situation, ils peuvent être enregistrés et « masqués » à l’aide de la commande git stash. Pour annuler les modifications, utilisez git stash apply .

Vous souhaiterez peut-être plutôt effacer toutes les modifications que vous avez apportées. Dans ce cas, utilisez la commande git clean. L'option -d supprimera également les fichiers non suivis. Astuce : ajoutez l'option -n pour voir ce qui se passe lorsque vous exécutez git clean sans l'utiliser directement.

Regroupement de succursales

Maintenant que nous avons expliqué ce que sont les branches et comment basculer entre elles, il est temps de parler de la manière dont elles peuvent être combinées après le développement. La branche dans laquelle nous souhaitons fusionner les modifications sera appelée la branche principale, et la branche à partir de laquelle nous les fusionnerons sera appelée la branche thématique. Il existe deux manières d'effectuer des modifications d'une branche à une autre : fusionner et déplacer.

Fusionnement

Cela implique la création d’un nouveau commit basé sur le commit ancêtre commun des deux branches et pointant vers les deux HEAD en tant que commits précédents. Pour fusionner, nous passons à la branche principale et utilisons la commande git merge<тематическая ветка> .

Si les deux branches modifient la même partie du fichier, un conflit de fusion se produit - une situation dans laquelle Git ne sait pas quelle version du fichier conserver, vous devez donc résoudre le conflit vous-même. Pour voir les fichiers en conflit, utilisez git status.

Après avoir ouvert ces fichiers, vous verrez des marqueurs de résolution de conflit similaires :

<<<<<<< HEAD:index.html Everything above the ==== is the version in master. ======= Everything below the ==== is the version in the test branch. >>>>>>> test:index.html

Remplacez tout ce qui se trouve dans ce bloc par la version que vous souhaitez conserver et préparez le fichier. Une fois tous les conflits résolus, vous pouvez utiliser git commit pour terminer la fusion.

En mouvement

Au lieu de fusionner deux branches avec une validation de fusion, move relit les validations de branche de sujet sous la forme d'un ensemble de nouvelles validations de branche de base, ce qui permet d'obtenir un historique de validation plus propre.

Pour déplacer, utilisez la commande git rebase<основная ветка> <тематическая ветка>, qui reproduit les évolutions du fil thématique sur le fil principal ; Le HEAD d’une branche de sujet pointe vers le dernier commit rejoué.

Déménager contre fusionnement

Après la fusion, le journal et l'historique peuvent sembler assez compliqués. D’un autre côté, bouger vous permet de réécrire l’histoire sous une forme normale et séquentielle.

Alors pourquoi avez-vous besoin de fusionner si vous pouvez utiliser le mouvement à tout moment ? Malheureusement, le déplacement n'est pas une panacée pour les journaux désordonnés, car les commits déplacés sont en réalité différents des commits d'origine, bien qu'ils aient le même auteur, le même message et les mêmes modifications.

Imaginons un scénario :

• Sur votre branche, vous créez plusieurs commits et les fusionnez dans la branche master.
• Quelqu'un d'autre décide de s'appuyer sur vos engagements.
• Vous décidez de déplacer vos commits et de les transmettre au serveur.
• Lorsque quelqu'un essaie de fusionner son travail en fonction de vos commits d'origine, nous nous retrouvons avec deux branches parallèles avec le même auteur, les mêmes messages et modifications, mais des commits différents.

Alors voici quelques conseils :

Déplacez uniquement les modifications sur votre branche locale privée - ne déplacez pas les validations dont dépend quelqu'un d'autre.

Annulation des validations - annuler et réinitialiser

Un débat similaire sur la meilleure utilisation survient lorsque vous souhaitez annuler une validation. commande git revert<коммит>crée un nouveau commit qui annule les modifications mais préserve l'historique, tandis que git reset<коммит>déplace le pointeur HEAD, fournissant un historique plus propre (comme si la validation n'avait jamais eu lieu). Il est important de noter que cela signifie également que vous ne pourrez pas revenir sur ces modifications, par exemple si vous décidez que l'annulation de la validation n'était pas nécessaire. Plus propre ne veut pas dire meilleur !

Résumons

À ce stade, vous disposez de presque tout ce dont vous avez besoin pour travailler avec Git. Vous trouverez ci-dessous quelques conseils avancés (facultatifs) pour plus de contrôle sur vos commits et votre historique. Nous aborderons également brièvement GitHub, l'une des plateformes Git les plus connues qui pourrait vous être utile.

GitHub

GitHub est une plateforme qui stocke les référentiels Git sur ses multiples serveurs. En tant qu'utilisateur de GitHub, vous pouvez héberger vos référentiels distants sur leurs serveurs, ainsi que contribuer à d'autres référentiels open source. GitHub ajoute de nouvelles fonctionnalités à votre expérience Git.

Par exemple, vous pouvez créer un référentiel distant, c'est-à-dire créer votre propre copie du référentiel dans le nord de GitHub. Ceci est utile dans les cas où vous n'avez pas les droits nécessaires pour créer une branche dans le référentiel d'origine. Lorsque vous utilisez la commande git clone, votre référentiel local suivra le fork distant en tant qu'origine et le référentiel d'origine en amont.

Après cela, vous devrez peut-être fusionner la branche thématique de votre référentiel distant dans la branche principale de celui d'origine. Pour ce faire, vous pouvez créer une nouvelle Pull Request, dans laquelle GitHub vérifie les conflits avant de vous autoriser à fusionner. Il existe souvent d'autres vérifications avant la fusion, telles que la révision et l'approbation du code ou même l'exécution de tests. Vous pouvez discuter du code dans une requête, et toutes les validations que vous transmettez vers une branche de sujet distante seront automatiquement ajoutées à la requête, même si elle a été créée avant ces validations.

Utilisation avancée : préparation interactive

Vous pouvez facilement gérer la zone de préparation (par exemple, lors de la validation de plusieurs petits commits au lieu d'un grand) à l'aide de la console interactive, que vous pouvez exécuter git add -i . Il y a 8 commandes disponibles :

• statut - affiche pour chaque fichier une brève description de ce qui est (non) préparé ;
• mise à jour - prépare les fichiers surveillés ;
• revenir - supprimez un ou plusieurs fichiers de la zone préparée ;
• ajouter un fichier non suivi - prépare un fichier non suivi ;
• patch - ne prépare qu'une partie du fichier (utile lorsque, par exemple, vous avez modifié plusieurs fonctions, mais que vous souhaitez diviser les modifications en plusieurs commits). Après avoir sélectionné un fichier, des fragments de celui-ci vous seront montrés et des commandes possibles vous seront présentées : Mettre en scène ce morceau ? . Puis-je entrer? pour voir ce que fait chaque commande ;
• diff - affiche une liste des fichiers préparés et vous permet de visualiser les modifications pour chacun d'eux ;
• quitter - quitte la console interactive ;
• help - affiche une brève description de chaque commande.

Un * à côté d'un fichier signifie que la commande changera d'état (préparée/non préparée selon qu'une mise à jour ou un rollback est en cours). Si vous appuyez sur Entrée sans rien entrer dans aucun des sous-menus de commande, tous les fichiers passeront à l'état (non) préparé.

Veuillez noter que la création de correctifs (préparation d'une partie seulement d'un fichier) est disponible non seulement dans la console interactive, mais également via la commande git add -p.

Utilisation avancée : édition de l'historique

Pour plus de contrôle sur l'historique des commits d'une branche locale, vous pouvez utiliser la commande git rebase -i HEAD~ n, qui ouvrira une console interactive pour déplacer un ensemble de données récentes n les commits sont classés du plus ancien au plus récent (c'est-à-dire dans l'ordre dans lequel ils seront déplacés). De cette façon, vous pouvez "modifier l'historique", mais rappelez-vous que les commits d'origine ne peuvent pas être modifiés, mais seulement déplacés.

Vous pouvez modifier l'ordre des validations en modifiant l'ordre dans lequel ils sont répertoriés.

Modification du message de validation/commits fractionnés

Pour spécifier le commit que vous souhaitez modifier, utilisez la commande edit. Ensuite, lorsque Git effectue un mouvement, il s'arrête à ce commit. Après cela, vous pouvez utiliser git commit --amend pour modifier le message ou préparer les fichiers oubliés. Si vous souhaitez diviser le commit, après l'arrêt, tapez git reset HEAD^ (cela fera reculer HEAD d'un commit et tous les fichiers modifiés dans ce commit passeront à l'état non préparé). Vous pouvez ensuite valider les fichiers dans des commits séparés, comme d'habitude.

Une fois que vous avez terminé l'édition, tapez git rebase --continue .

Réécriture de plusieurs commits

Parfois, vous devrez peut-être réécrire plusieurs commits – dans de tels cas, vous pouvez utiliser git filter-branch . Par exemple, pour supprimer un fichier qui a été accidentellement validé, vous pouvez taper git filter-branch --tree-filter "git rm -f<имя файла>" TÊTE . Cependant, notez que cela déplace toute l'histoire.

Fusionner plusieurs commits

Tout en travaillant sur une nouvelle fonctionnalité dans un projet, vous pouvez progressivement apporter les moindres modifications à une branche thématique. Cependant, à cause de cela, l'historique est encombré de commits si petits qu'ils peuvent violer les règles du projet. Cela peut être résolu en fusionnant plusieurs commits en un seul gros. Pour ce faire, utilisez d’abord la commande pick pour sélectionner le premier commit, puis écrasez les suivants. Git appliquera toutes les modifications dans un seul commit et vous demandera de modifier le message de commit global.

Déplacer un commit séparé

En plus de fusionner/déplacer tous les commits sur une branche thématique, vous pourriez n'être intéressé que par un commit spécifique. Supposons que vous ayez un fil de discussion local sur les brouillons dans lequel vous travaillez sur plusieurs articles potentiels, mais que vous ne souhaitez en publier qu'un seul. Pour ce faire, vous pouvez utiliser la commande git Cherry-pick. Pour obtenir des commits spécifiques parmi lesquels nous souhaitons choisir, nous pouvons utiliser git log<основная ветка>..<тематическая> .

Notez que cela crée un nouveau commit qui répète uniquement la différence du commit sélectionné (c'est-à-dire la différence entre ce commit et le précédent), mais pas son état.

Conclusion

Nous avons donc couvert les concepts de base de Git. Vous pouvez utiliser cet article comme référence rapide, ou vous pouvez lire le livre Pro Git, qui est beaucoup plus long (~ 450 pages) et couvre Git plus en profondeur.

Vous souhaitez approfondir Git, mais un gros livre ne vous suffit pas (ou trop) ? Alors vous devriez jeter un œil au nôtre.

Si vous avez décidé de faire vos premiers pas vers l'utilisation de VCS (Version Control System), vous devriez déjà comprendre à quel point cette chose est utile. L’utilisation de tels systèmes présente de nombreux avantages, mais ce n’est pas le sujet de cet article. Dans cet article, je vais vous expliquer comment commencer à travailler (sous Windows 7) avec l'un des systèmes de contrôle de version les plus populaires - Github.

Très souvent, dans la liberté d'expression, nous ne disons pas github, mais simplement git, désignant la ressource https://github.com, cependant, ce ne sont pas exactement les mêmes choses. La ressource GitHub elle-même est un shell Web d'un système de suivi et de gestion de nos projets. C'est une sorte de réseau social pour les développeurs et pas seulement pour PHP, mais aussi pour d'autres langages de programmation. Quant à Git lui-même, c'est le programme que nous installerons sur notre ordinateur/ordinateur portable.

Pour commencer, nous devrons télécharger deux programmes :

1. msysgit. Vous pouvez télécharger la dernière version ici -> Git
2. TortoiseGit (32 bits et 64 bits)

Après avoir téléchargé ces deux programmes, commençons à les installer.

Note! Nous devons d'abord mettre msysgit, et puis - TortueGit

Le processus d’installation de msysgit est intuitif, nous ne nous y attarderons donc pas. La seule chose est que tous les paramètres qui nous sont proposés lors du processus d'installation peuvent rester inchangés et laissés par défaut.

Indiquez l'élément que vous voyez sur l'écran ci-dessus.

Après avoir installé ces packages, considérez que la première étape est terminée. La deuxième étape consiste à accéder à notre référentiel Github.

Tout d’abord, nous devons nous inscrire sur le site https://github.com. L'inscription sur ce site est simple et peu différente des opérations similaires sur d'autres sites.

Note! Lors de votre inscription, veuillez indiquer le véritable email que vous utilisez.

Après cela, nous aurons besoin de l’adresse e-mail que nous avons fournie lors de l’inscription. Si vous avez soudainement oublié celui que vous avez spécifié lors de l'inscription, vous pouvez le voir dans la section Modifier le profil -> E-mails (https://github.com/settings/emails) et vous le verrez dans la fenêtre principale :

Nous avons terminé ici, nous devons maintenant générer une clé SSH. Il s'agit d'une signature numérique pour votre ordinateur. Pour obtenir cette clé, nous avons besoin du même git. Après l'avoir installé, un raccourci Git Bush devrait apparaître sur votre bureau. Double-cliquez dessus pour lancer la console.

Note! Si vous n'avez pas ce raccourci sur votre bureau, alors cette ligne de commande peut être appelée ainsi : sur le bureau, dans un espace vide, appelez le menu contextuel avec la souris et dans la liste des éléments vous retrouverez le même Git Buisson

Maintenant, sur la ligne de commande, vous devez exécuter la commande :

ssh-keygen -t rsa -C "E-mail de votre profil"

Après cela, le message « Entrer le fichier dans lequel enregistrer la clé » apparaîtra ici. Pour l’instant, nous allons tout laisser tel quel et appuyer simplement sur Entrée. On nous demande maintenant de saisir un mot de passe, pour l'instant nous sauterons cette étape en appuyant sur Entrée, mais plus tard, ce mot de passe pourra être saisi indépendamment. Après cela, nous générerons deux fichiers – l’un d’eux sera notre clé SSH.

Note! Vous n'avez peut-être pas installé le module ssh-keygen et la commande ci-dessus ne fonctionnera tout simplement pas et, par conséquent, la clé ne sera pas générée. Dans ce cas, téléchargez des programmes comme Putty. Plus de détails dans l'article sur Habr -> http://habrahabr.ru/. Ou utilisez une connexion HTTPS.

Si vous avez tout fait comme décrit dans ces instructions et n'avez rien modifié au cours du processus, alors les fichiers se trouveront ici : C:/users/(UserName)/.ssh/

Dans ce dossier, nous aurons besoin d'un fichier ida_rsa.pub, que vous devez ouvrir à l'aide d'un bloc-notes ordinaire et copier le contenu dans le presse-papiers (en termes simples, dans le fichier ouvert, appuyez sur Ctrl+A, puis sur Ctrl+C).

La prochaine étape de configuration consiste à ajouter cette clé à votre profil Github. Pour ce faire, accédez aux paramètres de votre profil : Paramètres -> Clés SSH et cliquez sur le bouton Ajouter une clé SSH, comme indiqué dans la capture d'écran ci-dessous.

Un formulaire avec deux champs s'est ouvert devant vous :

1. Titre

Laissez le titre vide, mais dans le champ Clé, collez le texte que vous avez copié précédemment à partir du fichier ida_rsa.pub.

Félicitations, une autre étape est terminée. Encore un peu et vous pourrez profiter de travailler dans votre propre référentiel.

Créez maintenant un dossier séparé sur l'hôte local dans lequel votre projet sera stocké et appelez le menu contextuel dessus. Sélectionnez ensuite TortoiseGit -> Paramètres comme indiqué dans la capture d'écran :

Dans la fenêtre qui s'ouvre à gauche, vous verrez un menu arborescent. Vous devez sélectionner Git -> Config et noter votre nom et votre adresse e-mail exactement comme vous l'avez indiqué lors de votre inscription sur Github.

Nous devons maintenant cloner (copier) le référentiel sur notre ordinateur. Pour cela, rendez-vous sur votre dépôt créé sur Github et à droite vous verrez son adresse :

Copiez cette adresse dans votre presse-papiers. Appelez maintenant le menu contextuel du dossier que vous avez créé pour votre projet et sélectionnez la commande " Cloner Git...":

Une fenêtre s'est ouverte dans laquelle nous devons coller l'adresse copiée de notre référentiel :

Faites attention au champ Répertoire - parfois un autre dossier peut être ajouté. Assurez-vous que le chemin d'accès mène à votre dossier de projet et non à un autre. Cliquez maintenant sur OK. Le clonage commence :

Suite de l'article sur l'utilisation de Git. Apprendre à ajouter des fichiers, à valider et à pousser >

GitHub - qu'est-ce que c'est ? Cette ressource est une plateforme Web de contrôle de version et de collaboration destinée aux développeurs de logiciels. Fourni via un modèle commercial de logiciel en tant que service, il a été lancé en 2008. La ressource est basée sur Git, un système de gestion de code source conçu pour accélérer le développement de logiciels.

GitHub est actuellement le service d'hébergement de code le plus populaire parmi les développeurs et les programmeurs.

GitHub - qu'est-ce que c'est ?

Git est utilisé pour stocker le code source d'un projet et garder une trace d'un historique complet de toutes les modifications du code. Cela permet aux développeurs de collaborer plus efficacement sur un projet en fournissant des outils pour gérer d'éventuelles modifications conflictuelles provenant de plusieurs développeurs. Travailler avec GitHub vous permet d'adapter et d'améliorer gratuitement les logiciels de ses référentiels publics, mais des frais pour les référentiels privés, proposant différents plans tarifaires. Chaque référentiel public ou privé contient tous les fichiers du projet, ainsi que l'historique des modifications de chaque fichier. Les référentiels peuvent avoir plusieurs employés et peuvent être publics ou privés.

Comment travailler sur GitHub ?

La plateforme facilite le codage social en fournissant une interface Web pour un référentiel de code Git et des outils de gestion pour la collaboration. Ce projet peut être considéré comme une ressource sérieuse de réseautage social pour les créateurs de logiciels.

Comment les participants peuvent coder ensemble, évaluer le travail de chacun, recevoir des mises à jour sur des projets spécifiques et communiquer publiquement ou en privé.

Les utilisateurs peuvent ajouter d'autres participants à leur projet pour collaborer.

Terminologie

Trois termes importants utilisés par les développeurs dans l'environnement GitHub.com sont fork, pull request et merge.

Un fork est un référentiel qui a été copié du compte d'un participant vers le compte d'un autre. Cet outil permet au développeur d'apporter des modifications sans affecter le code source.

Parce que GitHub est intuitif et facile à utiliser, et que ses outils de contrôle de version sont utiles pour la collaboration, la ressource est devenue populaire parmi les spécialistes de divers domaines, y compris les non-programmeurs. Ils ont notamment commencé à l'utiliser pour travailler sur des documents et des développements multimédias. Par exemple, des projets de documentation, des ressources d'apprentissage et d'autres types de travaux dans lesquels les utilisateurs peuvent interagir en ligne et travailler ensemble. GitLab est une alternative open source à GitHub.com.

Produits et fonctionnalités

En plus du célèbre produit GitHub.com, le fondateur du SaaS propose une version on-premise. GitHub Enterprise prend en charge les environnements de développement intégrés, les outils intégrés et une variété d'applications et de services tiers. La ressource offre des capacités de sécurité et de vérification accrues.

Les autres produits et fonctionnalités de l'application incluent :