Enregistrer des changements

git add

The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn't really affect the repository in any significant way—changes are not actually recorded until you run git commit.

In conjunction with these commands, you'll also need git status to view the state of the working directory and the staging area.

Utilisation

git add <fichier>

Stage all changes in <file> for the next commit.

git add <répertoire>

Stage all changes in <directory> for the next commit.

git add -p

Begin an interactive staging session that lets you choose portions of a file to add to the next commit. This will present you with a chunk of changes and prompt you for a command. Use y to stage the chunk, n to ignore the chunk, s to split it into smaller chunks, e to manually edit the chunk, and q to exit.

Discussion

The git add and git commit commands compose the fundamental Git workflow. These are the two commands that every Git user needs to understand, regardless of their team’s collaboration model. They are the means to record versions of a project into the repository’s history.

Developing a project revolves around the basic edit/stage/commit pattern. First, you edit your files in the working directory. When you’re ready to save a copy of the current state of the project, you stage changes with git add. After you’re happy with the staged snapshot, you commit it to the project history with git commit.

The git add command should not be confused with svn add, which adds a file to the repository. Instead, git add works on the more abstract level of changes. This means that git add needs to be called every time you alter a file, whereas svn add only needs to be called once for each file. It may sound redundant, but this workflow makes it much easier to keep a project organized.

Zone de staging

La zone de staging est une fonctionnalité vraiment propre à Git. Vous aurez certainement besoin d'un temps d'adaptation si vous avez effectué une migration depuis un environnement SVN (ou même Mercurial). Pour vous aider, vous pouvez considérer cette fonctionnalité comme un tampon entre le répertoire de travail et l'historique du projet.

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.

Exemple

When you’re starting a new project, git add serves the same function as svn import. To create an initial commit of the current directory, use the following two commands:

git add .
git commit

Once you’ve got your project up-and-running, new files can be added by passing the path to 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.

git commit

The git commit command commits the staged snapshot to the project history. Committed snapshots can be thought of as “safe” versions of a project—Git will never change them unless you explicity ask it to. Along with git add, this is one of the most important Git commands.

While they share the same name, this command is nothing like svn commit. Snapshots are committed to the local repository, and this requires absolutely no interaction with other Git repositories.

Utilisation

git commit

Commit the staged snapshot. This will launch a text editor prompting you for a commit message. After you’ve entered a message, save the file and close the editor to create the actual commit. git commit -m "<message>"

Commit the staged snapshot, but instead of launching a text editor, use <message> as the commit message.

git commit -a

Commit a snapshot of all changes in the working directory. This only includes modifications to tracked files (those that have been added with git add at some point in their history).

Discussion

Snapshots are always committed to the local repository. This is fundamentally different from SVN, wherein the working copy is committed to the central repository. In contrast, Git doesn’t force you to interact with the central repository until you’re ready. Just as the staging area is a buffer between the working directory and the project history, each developer’s local repository is a buffer between their contributions and the central repository.

Cela change le modèle de développement de base pour les utilisateurs de Git. Au lieu d'apporter un changement et de le commiter directement dans le dépôt centralisé, les développeurs Git peuvent accumuler les commits dans leur dépôt local. Cela présente de nombreux avantages par rapport à la collaboration de type SVN : il est notamment plus facile de séparer une fonctionnalité en commits atomiques, de regrouper des commits connexes et de nettoyer l'historique local avant de le publier dans le dépôt centralisé. Cela permet également aux développeurs de travailler dans un environnement isolé, repoussant l'intégration jusqu'à ce qu'ils soient prêts.

Instantanés, pas de différence

Aside from the practical distinctions between SVN and Git, their underlying implementation also follow entirely divergent design philosophies. Whereas SVN tracks differences of a file, Git’s version control model is based on snapshots. For example, an SVN commit consists of a diff compared to the original file added to the repository. Git, on the other hand, records the entire contents of each file in every commit.

Les opérations Git sont donc plus rapides que SVN, puisqu'il est inutile d'assembler une version spécifique d'un fichier à partir de ses différences : la révision complète de chaque fichier est immédiatement disponible dans la base de données interne de Git.

Le modèle d'instantané Git a un impact considérable sur la plupart des aspects de son modèle de contrôle de version, des outils de branching et de merging à ses workflows de collaboration.

Exemple

The following example assumes you’ve edited some content in a file called hello.py and are ready to commit it to the project history. First, you need to stage the file with git add, then you can commit the staged snapshot.

git add hello.py
git commit

This will open a text editor (customizable via git config) asking for a commit message, along with a list of what’s being committed:

# Saisissez le message de commit pour vos changements. Les lignes commençant
# par '#' seront ignorées, et un message vide annule le commit.
# Sur la branche master
# Changements à commiter :
# (utilisez "git reset HEAD <fichier>..." pour annuler le staging)
#
#modifié : hello.py

Git n'exige pas que les messages de commit suivent des contraintes de formatage spécifiques, mais le format canonique consiste à résumer le commit entier sur la première ligne (en moins de 50 caractères), à laisser une ligne vierge, puis à fournir une explication détaillée de ce qui a changé. Par exemple :

Change the message displayed by hello.py
- Update the sayHello() function to output the user's name
- Change the sayGoodbye() function to a friendlier message

Remarque : de nombreux développeurs aiment rédiger leurs messages de commit au présent. Cela leur permet de leur donner un ton plus actif dans le dépôt, ce qui rend un grand nombre d'opérations de réécriture de l'historique plus intuitives.