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`
Après
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
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.
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.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
git rebaseest 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-fpour 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-favec 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/masterLa machine de Jerry a également deux branches
master,origin/masterLes 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 fetchetgit push, leursorigin/masterrestent inchangés.Le repo de Jerry est le suivant
Le dépôt de Tom est le suivant :
.T1etJ1dans 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/masterlocal avancera et sera cohérent avec le pointeurmaster, comme suitLe 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 ilgit fetchle fait et met le dépôt distant, qui a été soumis par Tom avantT1Il a été transféré dans son dépôt local, comme suitL'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 JerryJ1n'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 à utilisergit rebasepour réécrire l'historique deJ1. sera la suivanteNotez que
AprèsJ1a été réécrit aprèsT1et est devenuJ1`git push, dépôt localEt le dépôt à distance
Exceptionnellement détendu, une ligne droite, rien
-fDonc, si vous souhaitez garder l'arbre bien rangé sans utiliser
-f, la méthode est la suivante : avantgit push, d'abordgit fetch, puisgit rebase.Lecture hautement recommandée
À moins que vous ne soyez le seul à l'utiliser, quiconque utilise
push --forcedevrait mourir.Liaison (suivi) des succursales locales et des succursales distantes, plus stratégie de rebase :
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.
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
En ce qui me concerne. Si vous devez utiliser
push -faprè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.