Ne cacher que les changements par étapes dans git - est-ce possible?

Existe-t-il un moyen de stocker uniquement mes modifications par étapes? Le scénario avec lequel je rencontre des problèmes est lorsque j'ai travaillé sur plusieurs bogues à un moment donné et que j'ai plusieurs modifications non mises en scène. J'aimerais pouvoir mettre en scène ces fichiers individuellement, créer mes fichiers .patch et les ranger jusqu'à ce que le code soit approuvé. De cette façon, quand il est approuvé, je peux ranger toute ma session (en cours), faire apparaître ce bogue et pousser le code.

Suis-je en train de mal faire ça? Suis-je en train de mal comprendre comment git peut fonctionner de différentes manières pour simplifier mon processus?

Oui, c'est possible avec DOUBLE STASH

1. Mettez en scène tous vos fichiers que vous devez ranger.
2. Courez git stash --keep-index. Cette commande créera une cachette avec TOUTES vos modifications (par étapes et non par étapes ), mais laissera les modifications par étapes dans votre répertoire de travail (toujours à l'état par étapes).
3. Courir git stash push -m "good stash"
4. Maintenant, votre fichier"good stash" contient uniquement des fichiers intermédiaires .

Maintenant, si vous avez besoin de fichiers non organisés avant le stockage, appliquez simplement le premier stockage ( celui créé avec--keep-index ) et vous pouvez maintenant supprimer les fichiers que vous avez stockés "good stash".

Prendre plaisir

Avec le dernier git, vous pouvez utiliser l' --patchoption

git stash push --patch  

git stash save --patch   # for older git versions

Et git vous demandera chaque modification de vos fichiers à ajouter ou non dans la cachette.
Vous venez de répondre youn

Alias UPD pour DOUBLE STASH :

git config --global alias.stash-staged '!bash -c "git stash --keep-index; git stash push -m "staged" --keep-index; git stash pop stash@{1}"'

Vous pouvez maintenant mettre en scène vos fichiers, puis exécuter git stash-staged.
En conséquence, vos fichiers intermédiaires seront enregistrés dans la cachette .

Si vous ne souhaitez pas conserver les fichiers intermédiaires et que vous souhaitez les placer dans la réserve. Ensuite, vous pouvez ajouter un autre alias et exécuter git move-staged:

git config --global alias.move-staged '!bash -c "git stash-staged;git commit -m "temp"; git stash; git reset --hard HEAD^; git stash pop"'

J'ai fait un script qui ne cache que ce qui est actuellement mis en scène et laisse tout le reste. C'est génial quand je commence à faire trop de changements sans rapport. Il vous suffit de mettre en scène ce qui n'est pas lié au commit souhaité et de le cacher.

(Merci à Bartłomiej pour le point de départ)

#!/bin/bash

#Stash everything temporarily.  Keep staged files, discard everything else after stashing.
git stash --keep-index

#Stash everything that remains (only the staged files should remain)  This is the stash we want to keep, so give it a name.
git stash save "$1"

#Apply the original stash to get us back to where we started.
git stash apply stash@{1}

#Create a temporary patch to reverse the originally staged changes and apply it
git stash show -p | git apply -R

#Delete the temporary stash
git stash drop stash@{1}

TL; DR Il suffit d'ajouter -- $(git diff --staged --name-only)pour votre <pathspec>paramètre git

Voici un simple doublure:

git stash -- $(git diff --staged --name-only)

Et pour ajouter un message simplement:

git stash push -m "My work in progress" -- $(git diff --staged --name-only)

Testé sur v2.17.1 et v2.21.0.windows.1

Limites:

• Veuillez noter que cela stockera tout, si aucun fichier n'est organisé.
• De plus, si vous avez un fichier qui n'est que partiellement mis en scène (c.-à-d. Seulement certaines lignes modifiées, sont mises en scène alors que d'autres lignes modifiées ne le sont pas), alors le fichier entier sera mis en cache (y compris les lignes non mises en scène).

Pour accomplir la même chose ...

1. Mettez en scène uniquement les fichiers sur lesquels vous souhaitez travailler.
2. git commit -m 'temp'
3. git add .
4. git stash
5. git reset HEAD~1

Boom. Les fichiers dont vous ne voulez pas sont cachés. Les fichiers que vous souhaitez sont tous prêts pour vous.

Dans ce scénario, je préfère créer de nouvelles branches pour chaque problème. J'utilise un préfixe temp / donc je sais que je peux supprimer ces branches plus tard.

git checkout -b temp/bug1

Mettez en scène les fichiers qui corrigent bug1 et validez-les.

git checkout -b temp/bug2

Vous pouvez ensuite sélectionner les commits dans les succursales respectives et soumettre une demande de tirage.

Pourquoi ne commettez-vous pas la modification pour un certain bogue et ne créez-vous pas de correctif à partir de cette validation et de son prédécesseur?

# hackhackhack, fix two unrelated bugs
git add -p                   # add hunks of first bug
git commit -m 'fix bug #123' # create commit #1
git add -p                   # add hunks of second bug
git commit -m 'fix bug #321' # create commit #2

Ensuite, pour créer les correctifs appropriés, utilisez git format-patch:

git format-patch HEAD^^

Cela va créer deux fichiers: 0001-fix-bug-123.patchet0002-fix-bug-321.patch

Ou vous pouvez créer des branches distinctes pour chaque bogue, de sorte que vous pouvez fusionner ou rebaser les correctifs de bogue individuellement, ou même les supprimer, s'ils ne fonctionnent pas.

git stash --keep-index est une bonne solution ... sauf qu'il ne fonctionnait pas correctement sur les chemins qui ont été supprimés, ce qui a été corrigé dans Git 2.23 (Q3 2019)

Voir commit b932f6a (16 juil.2019 ) par Thomas Gummerer ( tgummerer) .
^{(Fusionné par Junio ​​C Hamano - gitster- en commit f8aee85 , 25 juil.2019 )}

stash: correction de la gestion des fichiers supprimés avec --keep-index

git stash push --keep-index est censé conserver toutes les modifications qui ont été ajoutées à l'index, à la fois dans l'index et sur le disque.

Actuellement, cela ne se comporte pas correctement lorsqu'un fichier est supprimé de l'index.
Au lieu de le conserver supprimé sur le disque, ** - keep-index restaure actuellement le fichier. **

Corrigez ce comportement en utilisant ' git checkout' en mode sans superposition qui peut restaurer fidèlement l'index et l'arborescence de travail.
Cela simplifie également le code.

Notez que cela écrasera les fichiers non suivis si le fichier non suivi porte le même nom qu'un fichier qui a été supprimé dans l'index.

Cacher uniquement l'index (changements échelonnés) dans Git est plus difficile qu'il ne devrait l'être. J'ai trouvé que la réponse de @ Joe fonctionnait bien, et en ai transformé une variante mineure en cet alias:

stash-index = "!f() { \
  git stash push --quiet --keep-index -m \"temp for stash-index\" && \
  git stash push \"$@\" && \
  git stash pop --quiet stash@{1} && \
  git stash show -p | git apply -R; }; f"

Il pousse à la fois la mise en scène et les changements dans Unstaged une planque temporaire, laissant le seul mis en scène des changements. Il pousse ensuite les modifications par étapes dans la cachette, qui est la cachette que nous voulons conserver. Les arguments passés à l'alias, tels que ceux --message "whatever"qui seront ajoutés à cette commande stash. Enfin, il fait apparaître la cachette temporaire pour restaurer l'état d'origine et supprimer la cachette temporaire, puis «supprime» finalement les modifications stockées du répertoire de travail via une application de patch inverse.

Pour le problème opposé de ne cacher que les modifications non mises en scène (alias stash-working), consultez cette réponse .

Est-il absolument nécessaire de travailler sur plusieurs bugs à la fois? Et par «à la fois», je veux dire «avoir des fichiers modifiés pour plusieurs bogues en même temps». Parce que sauf si vous en avez absolument besoin, je ne travaillerais que sur un bogue à la fois dans votre environnement. De cette façon, vous pouvez utiliser les branches locales et rebaser, ce que je trouve beaucoup plus facile que de gérer une stash / stage complexe.

Disons que le maître est au commit B. Maintenant, travaillons sur le bug # 1.

git checkout -b bug1

Vous êtes maintenant sur branch bug1. Apportez quelques modifications, validez, attendez la révision du code. C'est local, donc vous n'affectez personne d'autre, et cela devrait être assez facile de créer un patch à partir de git diffs.

A-B < master
   \
    C < bug1

Vous travaillez maintenant sur bug2. Aller Retour à maître avec git checkout master. Faire une nouvelle branche, git checkout -b bug2. Apportez des modifications, validez, attendez la révision du code.

    D < bug2
   /
A-B < master
   \
    C < bug1

Imaginons que quelqu'un d'autre engage E & F sur master pendant que vous attendez l'examen.

    D < bug2
   /
A-B-E-F < master
   \
    C < bug1

Une fois votre code approuvé, vous pouvez le rebaser sur master en procédant comme suit:

git checkout bug1
git rebase master
git checkout master
git merge bug1

Cela se traduira par les éléments suivants:

    D < bug2
   /
A-B-E-F-C' < master, bug1

Ensuite, vous pouvez pousser, supprimer votre branche locale bug1, et c'est parti. Un bogue à la fois dans votre espace de travail, mais en utilisant des branches locales, votre référentiel peut gérer plusieurs bogues. Et cela évite une danse de scène / stash compliquée.

Réponse à la question de ctote dans les commentaires:

Eh bien, vous pouvez revenir à la sauvegarde pour chaque bogue et ne travailler qu'avec un seul bogue à la fois. Au moins cela vous évite le problème de la mise en scène. Mais après avoir essayé cela, je trouve personnellement cela gênant. Les cachettes sont un peu désordonnées dans un graphique de journal git. Et plus important encore, si vous bousillez quelque chose, vous ne pouvez pas revenir en arrière. Si vous avez un répertoire de travail sale et que vous ouvrez une cachette, vous ne pouvez pas "annuler" cette fenêtre. Il est beaucoup plus difficile de bousiller les commits déjà existants.

Alors git rebase -i.

Lorsque vous rebasez une branche sur une autre, vous pouvez le faire de manière interactive (indicateur -i). Lorsque vous faites cela, vous avez la possibilité de choisir ce que vous voulez faire avec chaque commit. Pro Git est un livre génial qui est également en ligne au format HTML, et a une belle section sur le rebasage et le squash:

http://git-scm.com/book/ch6-4.html

Je vais voler leur exemple textuellement pour plus de commodité. Imaginez que vous avez l'historique de validation suivant et que vous souhaitez rebaser et écraser bug1 sur master:

    F < bug2
   /
A-B-G-H < master
   \
    C-D-E < bug1

Voici ce que vous verrez lorsque vous tapez git rebase -i master bug1

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Pour écraser toutes les validations d'une branche vers le bas en une seule validation, conservez le premier commit comme "pick" et remplacez toutes les entrées "pick" suivantes par "squash" ou simplement "s". Vous aurez également la possibilité de modifier le message de validation.

pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

Alors oui, écraser est un peu pénible, mais je le recommanderais toujours à une utilisation intensive des cachettes.

D'après vos commentaires à la réponse de Mike Monkiewicz, je suggère d'utiliser un modèle plus simple: utilisez des branches de développement régulières, mais utilisez l'option squash de la fusion pour obtenir un seul commit dans votre branche principale:

git checkout -b bug1    # create the development branch
* hack hack hack *      # do some work
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
git checkout master     # go back to the master branch
git merge --squash bug1 # merge the work back
git commit              # commit the merge (don't forget
                        #    to change the default commit message)
git branch -D bug1      # remove the development branch

L'avantage de cette procédure est que vous pouvez utiliser le flux de travail git normal.

TL; DR ;git stash-staged

Après avoir créé un alias:

git config --global alias.stash-staged '!bash -c "git stash -- \$(git diff --staged --name-only)"'

Ici git diffrenvoie la liste des --stagedfichiers --name-only
Et puis nous passons cette liste comme pathspecà la git stashvirgule.

De man git stash:

git stash [--] [<pathspec>...]

<pathspec>...
   The new stash entry records the modified states only for the files
   that match the pathspec. The index entries and working tree
   files are then rolled back to the state in HEAD only for these
   files, too, leaving files that do not match the pathspec intact.

Pour élaguer une modification accidentelle, en particulier la suppression de plusieurs fichiers, procédez comme suit:

git add <stuff to keep> && git stash --keep-index && git stash drop

en d'autres termes, rangez la merde et jetez-la avec la cachette.

Testé dans git version 2.17.1