Rebase vs Merge: Intégration des changements dans GIT

Cet article poursuit notre série "Advanced Git". Suivez-nous sur Twitter ou abonnez-vous à notre newsletter pour des mises à jour sur les futurs articles!

La ramification GIT efficace est cruciale pour les développeurs. Mon article précédent a détaillé les stratégies de branchement, le modèle de branchement de Git, les types de branches et les flux de travail communs. L'avantage central: les espaces de travail isolés (branches) améliorent considérablement le contrôle des versions.

Cet article se concentre sur l'intégration des branches - fusionnant efficacement le code dans la ligne de développement principale. Nous explorerons deux méthodes clés: la fusion et la rebasses.

git merge et git rebase résolvent le même problème: l'intégration des changements d'une branche dans une autre. Cependant, leurs approches diffèrent considérablement. Examinons la fusion en premier.

Série avancée GIT:

• Partie 1: Création de l'engagement Git idéal
• Partie 2: Optimisation des stratégies de ramification GIT
• Partie 3: rationalisation de la collaboration avec les demandes de traction
• Partie 4: Résoudre efficacement les conflits de fusion
• Partie 5: Rebase vs Merge ( vous êtes ici! )
• Partie 6: Master Interactive Rebase
• Partie 7: La cueillette des cerises s'engage à Git
• Partie 8: Utiliser le réflog pour récupérer les engins perdus

Comprendre Git Merges

La commande git merge intègre les branches. Imaginez branch-B avec de nouveaux engins; fusionner dans branch-A :

 <code>$ git checkout branch-A $ git merge branch-B</code>

Cela crée un nouveau engagement de fusion sur branch-A , reliant les deux histoires de branche. Git identifie trois commits clés:

• L' ancêtre commun: le point où les deux branches partageaient le code identique avant de diverger.
• Les points de terminaison de la succursale: le dernier s'engage sur chaque branche, représentant leurs états actuels.

Git combine ces engagements pour atteindre l'intégration. Un scénario simplifié (où branch-A n'a pas de validation depuis la ramification) se traduit par une fusion "rapide" - ajoutant efficacement directement branch-B .

Cependant, dans la plupart des scénarios du monde réel, les deux branches ont évolué indépendamment. Git crée ensuite un engagement de fusion à combiner les modifications, un engagement distinct généré automatiquement, contrairement aux engagements créés par les développeurs. Comprendre cette fusion automatique nécessite d'analyser les histoires complètes des branches.

Les engagements humains vs fusifères

Les engagements créés par les développeurs sont soigneusement structurés, contenant des modifications connexes et des messages informatifs. Merger Commits, inversement, connectez automatiquement les branches, ne représentant pas nécessairement un ensemble de modifications sémantiquement cohérentes.

Intégrer à la rebasing

Rebasing offre une alternative à la fusion. Ce n'est pas intrinsèquement "mieux", juste différent. Vous pouvez gérer avec succès Git uniquement avec la fusion. Cependant, la compréhension de la rebasing offre des options précieuses.

Rebasing évite les engagements de fusion automatique, créant un historique de projet linéaire, éliminant les traces de divergence des branches.

Rebasing: un guide étape par étape

Rebase branch-B dans branch-A :

 <code>$ git checkout branch-A $ git rebase branch-B</code>

Le processus implique trois étapes:

1. La suppression temporaire des engagements: engage sur branch-A après que l'ancêtre commun soit temporairement stocké.
2. L'application des engagements de branch-B : les engagements de branch-B sont appliqués, alignant temporairement les deux branches.
3. Rebasing branch-A Commits: Les engins branch-A temporairement stockés sont réappliqués au-dessus des validations de branch-B , créant une histoire linéaire.

Le résultat: une histoire rationalisée sans fusion s'engage.

Les pièges potentiels de repasing

Surtout, les réécritures rebasées commettent l'histoire. Bien que le contenu reste le même, le parent de la commission change, générant un nouveau hachage SHA-1.

Ceci est acceptable pour les commits non publiés. Cependant, la rebasing Publié Commits est risqué, perturbant potentiellement les collaborateurs qui ont basé leur travail sur les commits originaux.

La règle d'or: ne réprimande jamais les succursales publiques! Utilisez la rebasse localement pour nettoyer votre historique avant de vous intégrer dans des branches partagées.

Stratégies d'intégration: fusionner vs rebase

La fusion et la rebasses sont deux outils précieux. La fusion préserve l'histoire de destructive. Rebasing rationalise l'histoire mais nécessite une prudence concernant les commits publiés.

Explorez mon "kit Git Advanced Git" gratuit pour des informations plus approfondies sur les outils Git.

Bonne fusion et rebasse! Rendez-vous dans le prochain épisode "Advanced Git"!

Série avancée GIT:

• Partie 1: Création de l'engagement Git idéal
• Partie 2: Optimisation des stratégies de ramification GIT
• Partie 3: rationalisation de la collaboration avec les demandes de traction
• Partie 4: Résoudre efficacement les conflits de fusion
• Partie 5: Rebase vs Merge ( vous êtes ici! )
• Partie 6: Master Interactive Rebase
• Partie 7: La cueillette des cerises s'engage à Git
• Partie 8: Utiliser le réflog pour récupérer les engins perdus

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!