Saving changes

Enregistrer des changements

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 master. 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.

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.

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.

Git Tutorial: git add Snapshot

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é à 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

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 de version, 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 

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

git add 

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

git add -p

Permet de commencer une session de staging interactif vous permettant de choisir des parties d'un fichier à ajouter au commit suivant. Un bloc de changements apparaîtra, et vous serez invité à entrer 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é

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant