La plupart des intégrations de code se produisent avec une fusion, mais parfois un développeur veut que son code local soit rattrapé par la branche master via une rebase à la place. Dans cet exemple, nous allons montrer comment git rebase une branche vers master au lieu d’utiliser la commande merge, tout en soulignant l’impact de l’exécution d’une opération git rebase vers master.
Qu’est-Git rebase pour maîtriser veux dire?,
dans ce tutoriel, nous allons prendre la branche nommée develop et la rebaser sur la pointe de master.
la branche develop s’est séparée de master au commit C, de sorte que les deux branches partagent les fichiers a.html, b.html et c.html. Voir l’image ci-dessous pour vous aider à visualiser cela.
Depuis que la branche s’est produite, master a ajouté des commits D et E. Cela signifie que master a deux fichiers que develop n’a pas, à savoir d.html et e.html.,
C’est la façon dont le dépôt Git ressemble avant un git rebase à maîtriser.
de plus, depuis la scission, il y a eu deux nouveaux commits sur la branche develop, ajoutant les fichiers f.html et g.html. Ce sont des fichiers que la branche develop a que la branche master n’a pas.
C’est la façon dont le GitLab référentiel de l’air après le git rebase à maîtriser.,
Impact du rebase Git
Après une rebase develop réussie vers master:
- les fichiers de la branche master ne changeront pas
- La branche develop acquerra en outre tous les nouveaux fichiers de la branche master
- Le point de branche du flux develop changera.
- il apparaîtra comme si la branche develop se divisait après la validation E sur la branche master.
- avant le rebase, la branche develop s’est séparée de master au commit C.,
syntaxe de la commande git rebase vers master
l’opération pour effectuer un rebase Git vers master est simple. Tout simplement ajouter à la fin de la commande le nom de la branche source et le nom de la branche de rebase. Pour rebaser develop TO master, la commande est la suivante:
git rebase master develop
avertissement: il existe un rebase git sur switch que les développeurs pensent parfois à tort qu’ils doivent inclure avec la commande rebase. Cela entraînera la suppression des commits et la perte de fichiers., Ne faites pas l’erreur d’effectuer un rebase git sur l’opération.
Avant cela, le fait de développer la branche n’avait que cinq fichiers.
Chaque branche a cinq fichiers avant le git rebase à la maîtrise de l’opération.
Après le rebase de Git vers master, la branche develop a sept fichiers. Il a conservé tous ses fichiers d’origine et a acquis deux nouveaux fichiers de la pointe de la branche master., Cependant, le nombre de fichiers dans la branche principale reste inchangé.
Après le git rebase de développer de maître, le fait de développer direction de la acquiert la totalité des fichiers.
le fait que la branche master n’ait acquis aucun fichier de la branche develop décourage souvent les nouveaux utilisateurs de Git, mais c’est le comportement attendu. Un rebase git ne se synchronise pas entre les branches. Il attrape simplement une branche avec les derniers changements d’une autre.,
Le nombre de fichiers à développer l’augmentation après la commande git rebase à maîtriser.
procéder avec prudence
lorsqu’un rebase Git se produit, l’historique des commits du dépôt est irrémédiablement modifié. Après le rebase dans notre exemple, les commits F et G se voient attribuer de nouveaux ID de commit, et les anciens ID de commit sont supprimés. Pour cette raison, vous verrez souvent des commits rebasés marqués comme F ‘et G’ pour souligner le fait que de nouveaux ID de commit ont été affectés.,
Si vous rebasez une branche partagée avec un autre développeur et repoussez vos modifications vers GitHub ou GitLab, un autre développeur rencontrera une variété ou des problèmes lorsqu’il tentera de tirer le référentiel rebasé dans son environnement de développement local. Les Commits qu’ils ont localement auront disparu sur la branche distante et la branche distante aura un historique de branche incompatible. Comme vous pouvez l’imaginer, le rebasage d’une branche partagée ou l’écrasement des commits Git peuvent causer des dégâts.,
Rebase vers GitHub ou GitLab
en fait, si vous rebase et essayez de pousser vers GitLab ou GitHub, le serveur ne permettra pas d’effectuer l’opération. Pour rebaser vers GitHub ou GitLab, un développeur doit ajouter le commutateur-force à la commande git push pour forcer les modifications à être acceptées.
git push origin --force
Un GitLab ou GitHub git rebase push sera rejetée à moins d’y être forcé.,
la logique acceptée est de ne rebaser git que pour maîtriser les branches locales de votre espace de travail personnel. De cette façon, vos commandes de nettoyage Git n’ont d’impact sur personne d’autre. N’effectuez pas de rebase Git à maîtriser sur les branches partagées avec d’autres développeurs. Un rebase sur master est bien, mais pas l’inverse. Sinon, vous risquez de casser la construction et les opérations push ou pull seront mises en veille, contrecarrant le développement continu et vous rendant persona non grata avec le reste des développeurs et de L’équipe DevOps.