Quand dois-je faire «git pull», avant ou après «git add, git commit»?

93

Quelle est la bonne façon?

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Ou

git pull
git add foo.js
git commit foo.js -m "commit"
git push

Ou

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

J'ai oublié de mentionner que dans ce cas, j'utilise git addpour mettre en scène un fichier suivi et modifié . Ne pas inclure un tout nouveau fichier dans le référentiel. Cela change-t-il l'ordre des commandes?

git

— vert
source

Question connexe: stackoverflow.com/questions/813822/…

— leo9r

95

Je pense que la meilleure façon de procéder est:

Stockez vos modifications locales:

git stash

Mettez à jour la branche avec le dernier code

git pull

Fusionnez vos modifications locales dans le dernier code:

git stash apply

Ajouter, valider et pousser vos modifications

git add
git commit
git push

D'après mon expérience, c'est le chemin vers la moindre résistance avec Git (sur la ligne de commande de toute façon).

— johnjo
source

4

Pouvez-vous expliquer pourquoi c'est mieux? Quels problèmes cela évite-t-il? En particulier, pourquoi est-ce mieux qu'un simple commit> pull> push? (Je pense que cela pourrait être la meilleure réponse, mais je n'ai pas assez d'informations pour le moment pour même être considérée comme une bonne réponse.)

— dallin

7

C'était peut-être trop anecdotique, mais j'ai toujours trouvé cette approche (en ligne de commande plutôt qu'avec quelque chose comme sourcetree) beaucoup plus facile. Faire un commit puis un pull, tout en travaillant dans une grande équipe, conduit toujours à de gros conflits de fusion car git n'était pas très bon pour fusionner mes modifications dans un fichier avec les entrées. En cachant, cela m'a permis d'extraire les nouvelles modifications, puis d'utiliser le code mis à jour comme base pour ajouter mes modifications à. Traiter les conflits était plus facile car ils étaient plus clairs pour moi (car mes changements étaient maintenant les conflits). Avec le recul, c'était peut-être plus facile pour ma situation.

— johnjo

1

Cela ressemble donc à une sorte de "Comment mangez-vous un éléphant? Une bouchée à la fois". c.-à-d. diviser le processus en quelques étapes supplémentaires pour simplifier les fusions pour avoir moins de changements et éventuellement plus clairs. Logique.

— dallin le

Git add est-il nécessaire ici? Si tous les fichiers sont déjà ajoutés à la mise en scène!

— Sharp Edge

Et si vous n'utilisez pas git stash?

— Aaron Franke

76

pull = chercher + fusionner.

Vous devez valider ce que vous avez fait avant de fusionner.

Alors tirez après validation.

— Arnaud Denoyelle
source

8

Cela signifierait-il que vous finissiez par faire un commit supplémentaire pour chaque commit que vous faites et rendre le dépôt bâclé? Votre message de validation initial se termine également suivi d'un commentaire de fusion à chaque fois. Si tel est le cas, je serais enclin à utiliser la méthode de dissimulation mentionnée ci-dessous par @johnjo.

— MondayPaper

3

@DanielM Oui, il y a un commit supplémentaire pour la fusion (avec un message de commit par défaut explicite). C'est plutôt une bonne chose car cela vous permet de récupérer votre dernier commit ou le dernier commit de votre collègue ou le commit de fusion. Si vous voulez l'éviter et si vous voulez placer vos commits après les commits de votre collègue, vous pouvez à la rebaseplace de merge. Vous pouvez le faire soit avec git commit && git rebaseou git pull --rebase.

— Arnaud Denoyelle

Merci pour la pointe, @Arnaud. Après avoir lu de nombreuses questions SO différentes, ce commentaire l'a fait. Mon option préférée lorsque des collègues travaillent sur différents fichiers est git pullaprès la préparation de mes modifications, car je trouve cela le plus naturel. Bien que je réalise que de nombreux flux de travail différents fonctionnent (le stash est bien aussi), c'est probablement une question de goût.

— nephewtom

51

Je suggérerais de sortir de la branche distante aussi souvent que possible afin de minimiser les fusions importantes et les conflits possibles.

Cela dit, j'irais avec la première option:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

Validez vos modifications avant de tirer afin que vos validations soient fusionnées avec les modifications à distance pendant l'extraction. Cela peut entraîner des conflits que vous pouvez commencer à gérer sachant que votre code est déjà validé en cas de problème et que vous devez abandonner la fusion pour une raison quelconque.

Je suis sûr que quelqu'un ne sera pas d'accord avec moi, je ne pense pas qu'il y ait de moyen correct de faire ce flux de fusion, seulement ce qui fonctionne le mieux pour les gens.

— Jasarien
source

1

Pourriez-vous s'il vous plaît voir ma mise à jour de la question? J'ai oublié d'expliquer à quoi git addsert exactement dans mon exemple.

— Vert

1

Cela ne devrait faire aucune différence, qu'il s'agisse d'un nouveau fichier ou d'un fichier suivi / modifié. Engagez-vous toujours, puis tirez.

— Jasarien

7

Je pense que git pull --rebasec'est le moyen le plus propre de définir vos commits localement récents en plus des commits à distance que vous n'avez pas à un certain moment.

Ainsi, vous n'avez pas à tirer chaque fois que vous souhaitez commencer à apporter des modifications.

— Mohyaddin Alaoddin
source

C'est ce que je fais aussi, mais juste pour souligner qu'il y a définitivement deux écoles de pensée principales à ce sujet (centrées sur la question de savoir s'il est préférable de résoudre les conflits entre les commits individuels, ou une fois dans le commit de fusion) avec Linus lui-même dans le camp de fusion . Heureusement, l'outil lui-même n'est pas avisé, alors utilisez-le, mais fonctionne mieux pour vous et les besoins de votre projet :-)

— Luke Usherwood

3

Vous voulez que votre modification soit placée au-dessus de l'état actuel de la branche distante. Vous voulez probablement tirer juste avant de vous engager. Après cela, poussez à nouveau vos modifications.

Les fichiers locaux "sales" ne sont pas un problème tant qu'il n'y a pas de conflit avec la branche distante. S'il y a des conflits, la fusion échouera, il n'y a donc aucun risque ou danger à tirer avant de valider les modifications locales.

— AlexE
source

1

Cela ne fonctionnera pas, comme Arnaud l'a mentionné, tirer nécessite que vous validiez d'abord vos modifications.

— Jasarien

Mon git semble heureux de tirer avec beaucoup de changements locaux. Bien sûr, si les mêmes fichiers sont modifiés sur la branche distante, la partie fusion de l'extraction échoue. Pour créer un conflit de fusion approprié, je devrais s'engager d'abord, bien sûr. Donc, si l'ensemble des fichiers modifiés localement et à distance est disjoint, tirer puis valider est très bien. Sinon, git ne tirera pas. Aucun dommage à faire en essayant.

— AlexE

C'est mon option préférée lorsque les gens travaillent sur différents fichiers, et je trouve que c'est la plus naturelle.

— nephewtom