git rebase est une réécriture de l'historique des commits. Lorsque l'historique de validation que vous souhaitez réécrire n'a pas été soumis au dépôt distant, c'est-à-dire avant qu'il ne soit partagé avec d'autres, l'historique de validation vous est privé, vous pouvez donc le réécrire comme vous le souhaitez .

Une fois soumis à la télécommande, si vous réécrivez l'histoire, elle sera certainement différente de l'histoire des autres. git push, git comparera l'historique de validation. S'il est incohérent, l'action de validation sera rejetée. Le seul moyen est d'utiliser le paramètre -f pour forcer la validation. À ce moment, git écrasera le dépôt distant avec le. l'historique du committer, complétez donc la soumission du code. Bien que le code ait été soumis, cela peut entraîner la perte du travail d'autres personnes, utilisez donc le paramètre -f avec prudence.

Le problème rencontré par l'affiche originale a été causé par la réécriture de l'historique des commits publics. Pour résoudre ce problème, nous devons standardiser le processus de soumission.

Donnez-moi un exemple du processus correct :

Supposons qu'il y ait deux développeurs dans l'équipe de l'affiche : Tom et Jerry utilisent conjointement un dépôt distant et le clonent sur leurs propres machines. Pour simplifier la description, on suppose qu'il n'y a qu'une seule branche : master.

À l'heure actuelle, le repo de Tom Machine a deux branches
master, origin/master
La machine de Jerry a également deux branches
master, origin/master

Les deux sont présentés dans l'image ci-dessous

Tom et Jerry développent chacun leurs propres nouvelles fonctionnalités, et les nouveaux commits sont constamment soumis à leurs historiques de commit privés respectifs, de sorte que leurs pointeurs principaux continuent d'avancer, pointant vers différents commits. Et comme aucun d'entre eux n'a git fetch et git push, leurs origin/master restent inchangés.

Le repo de Jerry est le suivant

Le dépôt de Tom est le suivant : T1 et J1 dans l'image ci-dessus sont deux commits différents

À ce moment-là, Tom soumet d'abord son commit au dépôt distant, puis son pointeur origin/master local avancera et sera cohérent avec le pointeur master, comme suit

Le dépôt à distance est le suivant

Maintenant, Jerry veut également soumettre son commit au dépôt distant, exécutez git push, et cela échoue sans aucune surprise, alors il git fetch le fait et met le dépôt distant, qui a été soumis par Tom avant T1 Il a été transféré dans son dépôt local, comme suit

L'historique des commits a bifurqué. Si vous souhaitez inclure le contenu que Tom a précédemment soumis dans votre propre travail, une solution consiste à git merge, ce qui générera automatiquement un commit incluant à la fois la soumission de Tom et celle de Jerry, donc. fusionner les deux commits fourchus ensemble. Cependant, ce commit généré automatiquement aura deux parents lors de la révision du code, il devra être comparé deux fois, ce qui est très gênant.

Afin d'assurer la linéarité de l'historique des commits, Jerry a décidé d'utiliser une autre méthode, qui est git rebase. Le commit de Jerry J1 n'a pas été soumis au dépôt distant pour le moment, ce qui est un commit qui lui est complètement privé, il n'y a donc aucun problème à utiliser git rebase pour réécrire l'historique de J1. sera la suivante

Notez que J1 a été réécrit après T1 et est devenu J1`

git push, dépôt local

Et le dépôt à distance

Exceptionnellement détendu, une ligne droite, rien-f

Donc, si vous souhaitez garder l'arbre bien rangé sans utiliser -f, la méthode est la suivante : avant git push, d'abord git fetch, puis git rebase.

git fetch origin master
git rebase origin/master
git push

Lecture hautement recommandée

• un modèle de branchement git réussi
• Rebase Git-branche-branche

À moins que vous ne soyez le seul à l'utiliser, quiconque utilise push --force devrait mourir.

Liaison (suivi) des succursales locales et des succursales distantes, plus stratégie de rebase :

[branch "master"]
    remote = origin
    merge = refs/heads/master
    rebase = true

De cette façon, lors de la mise à jour du code (pull), le rebase sera automatiquement appliqué au lieu de générer un commit de fusion, sauf s'il existe d'autres situations, telles que des conflits causés par une fusion tripartite qui nécessitent une intervention. La plupart du temps, c'est très intelligent. Tant que les habitudes de l'équipe sont bonnes, une forme d'arbre très propre et belle peut être maintenue.

En fait, il existe de nombreuses façons de rendre la structure arborescente plus belle et plus claire, mais cela dépend d'abord du type de modèle Git utilisé par l'équipe, et vous pouvez simplement prescrire le bon médicament. Il n'y a aucun moyen de le résumer ici.

De plus, la personne ci-dessus a raison, utilisez-la avec prudence push -f !

Cela devrait être un problème de workflow git. Notre équipe a utilisé le rebase pour garantir la propreté des informations de validation, mais nous n'utiliserons pas d'opérations telles que push -f.

Concernant le workflow git, c'est une question d'opinion. Vous pouvez lire les articles suivants et en trouver un qui convient à votre équipe. Mais le plus important est de vous assurer que tous les membres de l'équipe connaissent git.

• Construire des indices d'historique Git propres
• Un modèle de branchement Git réussi et largement diffusé
• Flux de travail Github

Si vous utilisez github pour le travail d'équipe, faites bon usage des pull request, cela peut résoudre push -fce problème stupide !

Tout le monde doit rebaser ses modifications sur le dernier code du serveur avant de les soumettre. Il n'y aura aucun problème si vous suivez cette règle. Si vous avez besoin d'une poussée forcée, cela signifie que vous le faites dans l'autre sens. Rebasez le code du serveur sur votre branche locale avant que la poussée forcée ne soit requise.

Il est recommandé de se référer au chapitre sur le rebase dans Pro Git http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88% 86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88

Risque de régénération
Eh bien, la merveilleuse dérivation n'est pas parfaite. Pour l'utiliser, vous devez respecter une règle :

Une fois l'objet commit de la branche publié dans l'entrepôt public, ne rebasez jamais la branche.

Si vous suivez cette règle d’or, rien ne peut aller mal. Sinon, les gens vous détesteront et vos amis et votre famille se moqueront de vous et vous rejetteront.

En ce qui me concerne. Si vous devez utiliser push -f après le rebase, cela doit signifier que l'opération de rebase est inappropriée. Sauf si vous avez l'intention de modifier l'historique des commits.

Il n'est pas nécessaire de pousser -f Si la branche est à la traîne, utilisez pull --rebase

Les réponses ci-dessus sont toutes correctes, personnellement, sauf si vous êtes le seul à travailler sur une certaine branche, il n'y aura aucun problème quelle que soit la façon dont vous rebasez, mais si vous êtes en maître. ou développerLorsque vous rebasez ce genre de branche, on estime que tout le monde dans l'équipe veut vous battre à mort, en particulier les coéquipiers qui ne connaissent pas git. Il est tout à fait normal d'être perdu.

Il n'y a qu'une seule situation dans laquelle push -f est poussé après le rebase, c'est-à-dire que le sujet souffre d'un trouble obsessionnel-compulsif comme moi et a peur de choses aussi douloureuses que les temps d'arrêt de l'ordinateur et les pannes du système (une histoire tragique de sang et larmes), et après avoir terminé une validation de fonctionnalité, poussez-la rapidement vers La télécommande n'appartient qu'à votre branche Afin d'obtenir les nouvelles fonctionnalités de développement, vous rebasez le développement sur votre propre branche chaque jour et effectuez. l’opération push à plusieurs reprises. Personnellement, je pense qu’il n’y a pas de problème. Après tout, vous n’affectez que vous-même (et vous savez que c’est vrai).

Personnellement, je pense qu'il est vraiment déraisonnable d'utiliser rebase lorsque vous travaillez en équipe sur une certaine branche. Et il est facile de se tromper. A utiliser avec prudence push --force

Le rebase Git est généralement utilisé lors du développement seul pour garder les enregistrements de soumission propres. Une fois téléchargé sur github, vous ne devez pas utiliser git rebase, sinon vous serez grondé à mort.