Fusion Git sans validation automatique

404

Est-il possible de faire un git merge, mais sans commit?

"man git merge" dit ceci:

With --no-commit perform the merge but pretend the merge failed and do not autocommit,
to give the user a chance to inspect and further tweak the merge result before
committing.

Mais quand j'essaie de l'utiliser git mergeavec le, --no-commitil se valide toujours automatiquement. Voici ce que j'ai fait:

$> ~/git/testrepo$ git checkout master
Switched to branch 'master'

$> ~/git/testrepo$ git branch
* master
  v1.0

$> ~/git/testrepo$ git merge --no-commit v1.0
Updating c0c9fd2..18fa02c
Fast-forward
 file1 |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

$> ~/git/testrepo$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Un suivant git logrévèle tous les commits de la branche v1.0 fusionnés dans master.

git

— selbie
source

618

Notez la sortie tout en faisant la fusion - c'est dire Fast Forward

Dans de telles situations, vous voulez faire:

git merge v1.0 --no-commit --no-ff

— manojlds
source

7

et s'il y a un conflit.

— Jürgen Paul

20

@PineappleUndertheSea Les avances rapides ne provoquent jamais de conflits. En cas de fusion "réelle" sans avance rapide, le --no-commitcommutateur n'est efficace que si aucun conflit ne se produit, en cas de conflit, git ne se validera jamais automatiquement.

— gronostaj

38

FYI: Si vous souhaitez fusionner les modifications, puis valider comme si vous aviez tapé manuellement toutes les modifications que vous avez fusionnées (par opposition à une fusion traditionnelle), vous devez exécuter rm .git/MERGE_HEADensuite, ce qui forcera git à oublier que la fusion s'est produite.

— Jonn

7

FYI: Voici un exemple de sortie pour une fusion réussie:Automatic merge went well; stopped before committing as requested

— kevinarpe

6

Apparemment, git merge BRANCHENAME --no-commit --no-ffj'ai laissé mon espace de travail dans un état "fusion". Je ne sais pas exactement ce que cela fait exactement, mais un cycle simple git stash saveet git stash popsemblait tout ramener à la normale; avec juste les fichiers modifiés de la branche cible en place comme prévu, et non plus un statut MERGING.

— MoonLite

49

Vous comprenez mal le sens de la fusion ici.

Le --no-commitempêche le MERGE COMMIT de se produire, et cela ne se produit que lorsque vous fusionnez deux historiques de branche divergents; dans votre exemple, ce n'est pas le cas, car Git indique qu'il s'agissait d'une fusion "d'avance rapide", puis Git applique uniquement les validations déjà présentes sur la branche de manière séquentielle.

— Samus_
source

12

Cela (imo) ne dissiperait pas nécessairement la confusion; Je pense que c'est une (relativement rare) fois où les documents sont vraiment clairs: git help merge=> "Avec --no-commiteffectuer la fusion mais faire semblant que la fusion a échoué et ne pas s'engager automatiquement, pour donner à l'utilisateur une chance d'inspecter et de peaufiner le résultat de la fusion avant de valider. " La clé est bien sûr de l'utiliser en conjonction avec--no-ff

— Michael

6

... il serait peut-être moins déroutant de rompre avec une terminologie stricte et de la décrire de cette façon: une "fusion de git" qui effectue une avance rapide n'a pas de commit de fusion car il n'y a en fait pas de fusion du tout. C'est en fait la situation idéale: les avances rapides sont une bonne chose, et ne pas avoir ce "commit de fusion" supplémentaire a du sens. Il s'agit d'un bon comportement par défaut et ne doit pas être désactivé. (Dans le langage propre, une avance rapide est un type de fusion, mais ce n'est pas une "vraie fusion".)

— michael

4

c'est par rapport aux politiques du projet, dans certains cas, il est utile d'avoir / forcer ces "validations de fusion" supplémentaires même si c'est un ff car vous devez marquer l'inclusion de la fonctionnalité dans la branche principale.

— Samus_

7

...quoi. Très bien, je pense que git est à peu près inviolable. Cette réponse en particulier m'a convaincu d'essayer Mercurial.

— Brian Gordon

24

Si vous souhaitez uniquement valider toutes les modifications en un seul commit comme si vous vous étiez entré, --squash fera de même

$ git merge --squash v1.0
$ git commit

— Adrian Li
source

1

Est-ce le même effet quegit merge v1.0 --no-commit --no-ff

— jpierson

2

Non, effet différent. Squash crée un nouveau commit avec un nouveau hachage. Il combine toutes les validations d'une branche en une seule validation pour la fusion.

— Kavi Siegel

23

Je préfère cette façon, donc je n'ai pas besoin de me souvenir de paramètres rares.

git merge branch_name

Il indiquera alors que votre branche est en avance par " #" les validations, vous pouvez maintenant supprimer ces validations et les mettre dans les modifications de travail avec les éléments suivants:

git reset @~#

Par exemple, si après la fusion, il y a 1 commit d'avance, utilisez:

git reset @~1

Remarque: sous Windows, des devis sont nécessaires. (Comme Josh l'a noté dans les commentaires), par exemple:

git reset "@~1"

— Pastille
source

4

Sur Windows, des devis sont nécessaires:git reset "@~1"

— Josh

1

Quand il n'y a qu'un seul commit dans la branche, je fais d'habitude

git merge branch_name --ff

— Sithu
source