Le principe de git (quand tu t'apprête à faire un commit sans -a), c'est que tu as l'« index », ou « staging area », qui est l'endroit où tu met ce que tu vas commiter. Pour mettre des choses dedans, tu fais « git add fichier ».
Exemple bête : tu veux faire un commit selectif sur les fichiers A.txt, B.txt, mais pas les autres :
Dans ce cas, tu aurais pu faire la même chose avec
$ git commit -m "..." A.txt B.txt
mais c'est assez pratique aussi de pouvoir prendre ton temps pendant que tu sélectionne les fichiers que tu veux. Par exemple, juste avant de commiter, tu peux faire « git diff » pour voir ce que tu as dans ton arbre de travail mais pas dans l'index, et « git diff --cached » pour voir ce que tu vas vraiment commiter. Avec des outils comme « git add --interactive » ou « git gui », tu peux même faire un commit selectif au niveau des portions de patch.
Avec la plupart des gestionnaires de versions, tu as des interfaces graphiques pour faire des commits selectifs. Tu sélectionne un certain nombre de fichiers, et tu as un bouton « commit » quelque part. Tu peux voir l'index comme ce système de selection de fichiers, mais c'est stoqué sur le disque, donc persistant entre deux appels.
Ceci dit, les commit selectifs, il faut s'en méfier. Ça veut dire que ce que tu commites n'a probablement jamais existé en temps que tel sur le disque, donc que ça n'a jamais vraiment été testé. Mais même pour des commits non-selectifs, ça peut être pratique. Par exemple, tu as un paquet de changement dans ton arbre de travail, et tu veux vérifier que tu n'as pas fait de conneries. « git diff » te montre ce qu'il te reste à vérifier, et en faisant « git add », tu valides le changement. A ce moment, tu ne fais commit que quand « git diff » ne dit plus rien (« git status » te donne la même info sous une autre forme).
C'est assez pénible au départ, mais on s'y fait, et après quelques semaines d'utilisation, c'est le système des autres outils que je trouve bizare ;-).
[^] # Re: git et mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Sondage pour utilisateurs de git. Évalué à 3.
Exemple bête : tu veux faire un commit selectif sur les fichiers A.txt, B.txt, mais pas les autres :
$ git add A.txt
$ git add B.txt
$ git commit -m "commit selectif machinbidule"
Dans ce cas, tu aurais pu faire la même chose avec
$ git commit -m "..." A.txt B.txt
mais c'est assez pratique aussi de pouvoir prendre ton temps pendant que tu sélectionne les fichiers que tu veux. Par exemple, juste avant de commiter, tu peux faire « git diff » pour voir ce que tu as dans ton arbre de travail mais pas dans l'index, et « git diff --cached » pour voir ce que tu vas vraiment commiter. Avec des outils comme « git add --interactive » ou « git gui », tu peux même faire un commit selectif au niveau des portions de patch.
Avec la plupart des gestionnaires de versions, tu as des interfaces graphiques pour faire des commits selectifs. Tu sélectionne un certain nombre de fichiers, et tu as un bouton « commit » quelque part. Tu peux voir l'index comme ce système de selection de fichiers, mais c'est stoqué sur le disque, donc persistant entre deux appels.
Ceci dit, les commit selectifs, il faut s'en méfier. Ça veut dire que ce que tu commites n'a probablement jamais existé en temps que tel sur le disque, donc que ça n'a jamais vraiment été testé. Mais même pour des commits non-selectifs, ça peut être pratique. Par exemple, tu as un paquet de changement dans ton arbre de travail, et tu veux vérifier que tu n'as pas fait de conneries. « git diff » te montre ce qu'il te reste à vérifier, et en faisant « git add », tu valides le changement. A ce moment, tu ne fais commit que quand « git diff » ne dit plus rien (« git status » te donne la même info sous une autre forme).
C'est assez pénible au départ, mais on s'y fait, et après quelques semaines d'utilisation, c'est le système des autres outils que je trouve bizare ;-).