Close

git add

Lorsque vous travaillez dans Git ou dans un autre système de contrôle de version, le concept d'« enregistrement » est un processus plus nuancé que dans un outil de traitement de texte ou d'autres applications d'édition de fichiers traditionnelles. Dans l'univers des logiciels, l'expression « enregistrer » classique est synonyme de « commiter » dans Git. Un commit est l'équivalent Git d'un enregistrement. Ce dernier devrait être considéré comme une opération sur un système de fichiers, qui est utilisée pour écraser un fichier existant ou en créer un. Ou, le commit Git est une opération qui agit sur un ensemble de fichiers et de répertoires.

Dans Git, l'enregistrement de changements diffère par rapport à SVN. Les commits ou « check-ins » SVN sont des opérations qui effectuent un push distant vers un serveur centralisé. Cela signifie qu'un commit SVN a besoin d'un accès à Internet pour enregistrer complètement les changements apportés au projet. Les commits Git peuvent être capturés et accumulés en local, avant d'être pushés vers un serveur distant au besoin à l'aide de la commande git push -u origin main. La différence entre les deux méthodes ? Une différence fondamentale dans les conceptions d'architecture. Git est un modèle d'application distribuée, tandis que SVN est un modèle centralisé. Les applications distribuées sont généralement plus solides, car elles ne disposent pas de point de défaillance unique comme un serveur centralisé.

Les commandes git add, git status et git commit sont toutes utilisées en combinaison pour enregistrer un instantané de l'état actuel d'un projet Git.

Git dispose d'un mécanisme d'enregistrement supplémentaire appelé le « stash ». Le stash est une zone de stockage temporaire pour les changements qui ne sont pas prêts à être commités. Il fonctionne sur le répertoire de travail, la première des trois arborescences, et possède des options d'utilisation étendues. Pour en savoir plus, consultez la page git stash.

Un dépôt Git peut être configuré de sorte à ignorer des fichiers ou des répertoires spécifiques. Cela empêche ainsi Git d'enregistrer des changements apportés à du contenu ignoré. Git propose plusieurs méthodes de configuration qui gèrent la liste « ignore ». La configuration « ignore » de Git est abordée plus en détail sur la page git ignore.


git add


La commande git add ajoute un changement dans le répertoire de travail à la zone de staging. Elle informe Git que vous voulez inclure les mises à jour dans un fichier particulier du commit suivant. Cependant, git add n'impacte pas le dépôt de manière significative. Les changements ne sont pas réellement enregistrés jusqu'à ce que vous exécutiez git commit.

Conjointement à ces commandes, vous avez également besoin de git status pour voir l'état du répertoire de travail et de la zone de staging.

Fonctionnement


Les commandes git add et git commit composent le workflow Git de base. Ce sont les deux commandes que chaque utilisateur de Git doit comprendre, quel que soit le modèle de collaboration de son équipe. Elles permettent d'enregistrer les versions d'un projet dans l'historique du dépôt.

Le développement d'un projet repose sur le processus de base qui s'articule autour de trois étapes : l'édition, le staging et les commits. En premier lieu, vous modifiez vos fichiers dans le répertoire de travail. Lorsque vous êtes prêt à enregistrer une copie de l'état actuel du projet, vous stagez les changements grâce à git add. Quand vous êtes satisfait de l'instantané stagé, vous le commitez dans l'historique du projet grâce à git commit. La commande git reset permet d'annuler un commit ou un instantané stagé.

Outre git add et git commit, une troisième commande, git push, est essentielle à l'exhaustivité du workflow Git collaboratif. git push permet d'envoyer les changements commités vers des dépôts distants à des fins de collaboration. Ainsi, d'autres membres de l'équipe peuvent accéder à un ensemble de changements enregistrés.

Instantané git add
branche git
Ressource connexe

branche git

Logo Bitbucket
DÉCOUVRIR LA SOLUTION

Découvrir Git avec Bitbucket Cloud

La commande git add ne doit pas être confondue avec svn add, qui ajoute un fichier dans le dépôt. En effet, git add fonctionne sur le niveau le plus abstrait des changements. Ceci signifie que git add doit être appelée à chaque fois que vous modifiez un fichier, tandis que svn add ne doit être appelée qu'une seule fois pour chaque fichier. Cela peut sembler redondant, mais ce workflow facilite considérablement la bonne organisation d'un projet.

Zone de staging


La fonction principale de la commande git add consiste à promouvoir les changements en attente dans le répertoire de travail vers la zone de staging Git. La zone de staging est l'une des fonctionnalités uniques de Git. Vous aurez peut-être besoin de temps pour la comprendre si vous migrez depuis un environnement SVN (voire Mercurial). Cela vous aidera de la considérer comme une zone tampon entre le répertoire de travail et l'historique du projet. La zone de staging est considérée comme l'une des « trois arborescences » de Git, avec le répertoire de travail et l'historique des commits.

Au lieu de commiter tous les changements apportés depuis le dernier commit, la zone de staging vous permet de regrouper les changements liés dans des instantanés ciblés avant de les commiter dans l'historique du projet. Autrement dit, vous pouvez apporter différents changements à des fichiers distincts, revenir en arrière et les séparer en commits logiques en ajoutant des changements liés au staging, puis les commiter un par un. Comme dans tout système de contrôle des révisions, il est important de créer des commits atomiques afin qu'il soit plus facile de suivre les bugs et d'inverser des changements avec un impact minime sur le reste du projet.

Options communes


git add <file>

Permet de stager tous les changements dans <fichier> pour le commit suivant.

git add <directory>

Permet de stager tous les changements dans <répertoire> pour le commit suivant.

git add -p

Permet de démarrer une session de staging interactif afin de choisir des parties d'un fichier à ajouter au commit suivant. Un bloc de changements apparaîtra, et vous serez invité à saisir une commande. Utilisez y pour stager le bloc, n pour l'ignorer, s pour le diviser en blocs plus petits, e pour le modifier manuellement et q pour quitter.

Exemples


Lorsque vous commencez un nouveau projet, git add a la même fonction que svn import. Pour créer un commit initial du répertoire actuel, utilisez les deux commandes suivantes :

git add .
git commit

Une fois que votre projet est prêt et qu'il est fonctionnel, de nouveaux fichiers peuvent être ajoutés en transmettant le chemin à git add :

git add hello.py
git commit

Les commandes ci-dessus permettent également d'enregistrer des changements apportés aux fichiers existants. À nouveau, Git ne fait pas la distinction entre les changements de staging effectués dans les nouveaux fichiers et ceux effectués dans les fichiers déjà ajoutés au dépôt.

Résumé


En bref, git add est la première commande d'une chaîne d'opérations qui indique à Git d'« enregistrer » un instantané de l'état actuel du projet dans l'historique des commits. Lorsqu'elle est utilisée seule, git add promeut les changements en attente du répertoire de travail vers la zone de staging. La commande git status permet d'examiner l'état actuel du dépôt et peut être utilisée pour confirmer une promotion git add. La commande git reset permet d'annuler une opération git add. La commande git commit est ensuite utilisée pour commiter un instantané de la zone de staging vers l'historique des commits du dépôt.


Partager cet article
Thème suivant

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Des personnes qui collaborent à l'aide d'un mur rempli d'outils

Le blog Bitbucket

Illustration DevOps

Parcours de formation DevOps

Démos Des démos avec des partenaires d'Atlassian

Fonctionnement de Bitbucket Cloud avec Atlassian Open DevOps

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up