Comment faire en sorte que git merge gère les changements non validés dans mon arbre de travail ?

Question

Un collègue et moi travaillons tous les deux sur la branche master en ce moment. J'ai du code dans mon arbre de travail que je ne veux pas livrer (déclarations de débogage et autres). Maintenant, s'il modifie certains de ces fichiers, je ne peux pas les fusionner :

$ git merge origin/master
Updating 1b8c5c6..eb44c23
error: Entry 'blah.java' not uptodate. Cannot merge.

Venant d'un milieu subversion, je suis habitué à ce que mon arbre de travail soit automatiquement fusionné lorsque je tire des modifications du référentiel et, s'il y a des conflits, je les résous manuellement.

La méthode la plus rapide que j'ai trouvée pour faire cela dans git est la suivante :

$ git stash
$ git merge origin/master
$ git stash pop

Il s'agit essentiellement de supprimer mes modifications non validées, d'effectuer la fusion et de réappliquer les modifications. Comment puis-je demander à merge de fusionner automatiquement mon arbre de travail avec les modifications que j'essaie d'intégrer ?

Answer 1

Oubliez tout ce que vous avez appris sur la subversion.

Il faut toujours s'engager avant d'introduire des changements externes.

Imaginez que vous ayez un arbre qui fonctionne à peu près correctement - il n'est peut-être pas parfait, mais vous faites des progrès. Puis vous allez faire une fusion et le code que vous apportez fait des ravages (il est lui-même bogué, il y a trop de conflits à gérer, etc...). Ne serait-il pas agréable de pouvoir annuler cela ?

Si vous vous engagez, vous pouvez le faire. Si vous ne le faites pas, vous ne ferez que souffrir.

Rappelez-vous : Ce que vous commettez n'est pas avoir est ce que l'on pousse, mais ce que l'on n'engage pas, on peut facilement le perdre.

Il suffit de faire ce qui est sûr et facile, c'est-à-dire s'engager tôt et s'engager souvent.

Answer 2

Pour autant que je sache, le mieux que vous puissiez faire est ce que vous avez déjà avec git stash . Je trouve moi aussi étrange que Merge ne veuille s'occuper que d'arbres propres.

Answer 3

• Si le travail local n'est pas engagé
  • Et vous avez introduit des fichiers complètement nouveaux qui n'existent pas dans la branche distante :
  • Ou bien les fichiers affectés par votre travail local ont ZÉRO chevauchement avec les fichiers affectés par les changements que vous devez extraire de la base de données distante :
    • Vous avez de la chance : git pull fonctionnera "tout simplement"
  • Dans le cas contraire :
    • Si vos modifications locales n'ont AUCUN chevauchement avec les modifications que vous tirez :
      • git stash fonctionnera :
        • git stash save
        • git pull
        • git stash pop
    • Si vos modifications locales ont QUELQUE chevauchement avec les modifications que vous tirez :
      • git stash nécessitera une résolution manuelle des conflits :
        • git stash save
        • git pull
        • git stash pop
        • résoudre les conflits de fusion
        • git reset
        • git stash drop
• Si un travail local est engagé
  • Et les fichiers affectés par votre travail local n'ont AUCUN chevauchement avec les fichiers affectés par
    • Vous avez de la chance : git pull fonctionnera "tout simplement"
    • Cependant : git pull --rebase fonctionnera "encore mieux" grâce à un historique plus propre
    • il n'y a pas de validation par fusion ; vos modifications seront validées après les modifications en amont
  • Dans le cas contraire :
    • git pull nécessitera une résolution manuelle des conflits :
      • git pull
      • résoudre les conflits de fusion
      • git add FILE pour chaque DOSSIER en conflit
      • git commit
    • git pull --rebase pourrait encore "mieux fonctionner" grâce à un historique plus propre
      • Cependant, la résolution des conflits de fusion pourrait s'avérer beaucoup plus difficile

Pour une explication détaillée, voir : https://happygitwithr.com/pull-tricky.html

Answer 4

Vous ne pouvez pas dire git merge pour fusionner les modifications sur les fichiers qui ont été modifiés par rapport à votre référentiel local. Cela vous évite de perdre vos modifications lorsqu'une fusion se passe mal.

Avec l'approche CVS et SVN de la fusion, si vous n'avez pas copié manuellement vos fichiers avant la mise à jour et qu'ils ont été brouillés lors de la fusion, vous devez les rééditer manuellement pour revenir à un état correct.

Si vous livrez vos modifications ou les cachez avant de procéder à une fusion, tout est réversible. Si la fusion ne se passe pas bien, vous pouvez essayer plusieurs façons de la faire fonctionner et opter pour celle qui fonctionne le mieux.

Si vous effectuez des modifications expérimentales ou de débogage, vous pouvez utiliser l'option git rebase pour les déplacer après les validations que vous obtenez via git merge pour faciliter leur élimination ou pour éviter de les pousser accidentellement dans un référentiel.

Il convient de noter que l'utilisation de git rebase sur une branche que vous avez poussée dans un dépôt partagé causera des problèmes à tous ceux qui tirent de ce dépôt.

Je préfère utiliser git stash dans ces cas, mais je ne l'utilise que si la fusion modifie des fichiers que j'ai édités et non validés.