Après avoir corrigé les conflits, git se plaint toujours ?

Question

En général, je rebase lorsque j'apporte des changements à mes coéquipiers, et j'ai souvent des conflits :

...
CONFLICT (content): Merge conflict in app/views/search/index.html.erb
Auto-merging public/stylesheets/application.css
CONFLICT (content): Merge conflict in public/stylesheets/application.css
Failed to merge in the changes.
Patch failed at 0001 organizing

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Ainsi, après avoir ouvert chaque fichier présentant un conflit, l'avoir corrigé, puis avoir validé les fichiers corrigés :

~/Projects/myApp[956f6e1...]% git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

J'obtiens toujours la même erreur...

~/Projects/myApp[64b3779...]% git rebase --continue                         
Applying: organizing
No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

J'ai en quelque sorte toujours eu ce problème, mais je suppose que je n'ai jamais vraiment choisi de m'y attaquer. git rebase --skip .

Comment résoudre le conflit de la bonne manière ?

Answer 1

Ainsi, après avoir ouvert chaque fichier présentant un conflit, l'avoir corrigé puis avoir validé les fichiers corrigés...

Le problème, c'est que vous n'êtes pas censé le faire commit les correctifs. I a.txt a un conflit de fusion, alors le journal du shell devrait ressembler à ceci :

$ vim a.txt # fix conflict
$ git add a.txt
$ # no commit between add and rebase!
$ git rebase --continue

Appel git rebase --continue s'occupera de la livraison elle-même.

Je ne sais pas comment revenir à l'état antérieur à la validation, lorsque l'on est au milieu d'une refonte. git reset --hard HEAD ferait probablement l'affaire, mais personnellement je me sentirais plus en sécurité en allant directement à git rebase --abort et de recommencer sans s'engager au milieu.

Answer 2

Je suis d'accord avec Mark Rushakoff pour dire que la correction des erreurs ne devrait pas inclure leur correction.

Il y a au moins une autre façon pour git de continuer à dire que "Vous devez éditer tous les conflits de fusion et les marquer comme résolus en utilisant git add" même après avoir fait cela. Cela peut se produire si vous supprimez des fichiers du contrôle de version de git, mais que vous laissez le fichier non versionné dans votre arbre de travail et que vous essayez ensuite d'effectuer un rebase.

J'ai pu résoudre ce problème de la manière suivante :

1. Terminer le rebasement avec git rebase --abort
2. Déterminer le fichier incriminé en examinant git status
3. J'ai déplacé mes fichiers non versionnés dans mon tmp répertoire
4. Refaire la base - dans mon cas git svn rebase
5. Si vous voulez que le fichier non versionné traîne, déplacez-le là où vous le voulez (j'ai laissé le mien dans mon répertoire tmp).

J'espère que cela vous aidera.

Answer 3

Lorsque cela m'est arrivé, j'ai réussi à résoudre le problème après m'être rendu compte que j'avais édité (et ajouté à l'index) pendant la refonte un fichier qui n'a pas de conflit Je me suis dit que c'était peut-être une erreur. J'ai donc utilisé git checkout -- <filename-with-no-conflict> et ensuite git rebase --continue et cela a fonctionné.

Answer 4

Avec Git 2.14 (Q3 2017), ce type de conseil donné dans une question rhétorique qui n'appelle pas de réponse (comme " did you forget to use 'git add'? ") n'existera plus.

Voir commit 6963893 , commettre 9932242 , commit 6c48686 (11 mai 2017) par Jean-Noël Avila ( jnavila ) .
(fusionné par Junio C Hamano -- gitster -- en commit e638108 , 29 mai 2017)

facilité d'utilisation : ne pas poser de questions si aucune réponse n'est requise

Lorsque l'orthographe d'une commande contient erreurs, le programme git tente d'aider l'utilisateur en lui proposant des candidats qui sont proches de la commande inexistante. Par exemple, Git imprime la commande suivante :

    git: 'stahs' is not a git command. See 'git --help'.
    Did you mean this?

    stash

et sort ensuite.

Le problème de cette indication est qu'elle n'est pas formellement indiquée comme étant un et que l'utilisateur est en fait encouragé à répondre à la question, alors que la commande Git est déjà terminée.

L'utilisateur a eu la malchance de et a répondu "oui" sur la ligne de commande, ce qui a eu pour effet d'augmenter le nombre d'utilisateurs. yes programme.

L'erreur initiale est que le ligne de commande (sans interaction) ne doivent pas poser de questions, parce que ces questions nécessiteraient normalement une réponse de l'utilisateur qu'ils ne gèrent pas en effet. C'est une source de confusion au niveau de l'UX .

Afin d'améliorer la convivialité générale de la suite Git, la règle suivante a été adoptée suivante a été appliquée :

si la phrase

• apparaît dans une session non interactive
• est imprimé en dernier avant la sortie
• est une question adressée à l'utilisateur ("vous")

la phrase devient affirmative et propose l'option.

Dans votre cas, " did you forget to use 'git add'? " est désormais remplacé par :

Vous devriez ' git add ' chaque fichier avec des conflits résolus pour les marquer comme tels.
Il se peut que vous exécutiez git rm sur un fichier pour accepter la mention "supprimé par eux".

Beaucoup plus clair.

Answer 5

J'avais des conflits de fusion que j'avais réglés, mais je voyais encore des problèmes d'ordre sexuel.

Vous avez des chemins nonmergés.

Tout ce que j'avais à faire, c'était git add <file that had conflicts> et tout est rentré dans l'ordre.