Lorsque vous utilisez git rebase au lieu de git merge?

C'est simple, avec rebase vous dites d'utiliser une autre branche que la nouvelle base pour votre travail.

Si vous avez par exemple, une branche est master et de créer une branche pour mettre en œuvre une nouvelle fonctionnalité, vous dire le nom, il cool-feature, bien sûr, la branche master est la base de votre nouvelle fonctionnalité.

Maintenant à un certain point, vous voulez ajouter la nouvelle fonctionnalité vous mis en œuvre dans le master branche. Vous pouvez simplement passer à master et fusionner les cool-feature branche:

$ git checkout master
$ git merge cool-feature

mais de cette façon, un nouveau mannequin commettre est ajouté, si vous voulez éviter de spaghettis l'histoire, vous pouvez rebase:

$ git checkout cool-feature
$ git rebase master

puis de les fusionner en master:

$ git checkout master
$ git merge cool-feature

Cette fois, puisque le sujet de la branche a la même commet de master plus les commits avec la nouvelle fonctionnalité, la fusion sera juste une avance rapide.

TL;DR

Si vous avez un doute, utilisez fusionner les.

Réponse Courte

Les seules différences entre un rebase et de fusion sont:

• L'arbre résultant de la structure de l'histoire (en général seulement visible lorsque l'on regarde un commit graphique) est différent (on aura branches, l'autre ne va pas).
• Fusion sera en général de créer un supplément de commettre (par exemple, le nœud dans l'arbre).
• De fusion et rebase résoudre les conflits de manière différente. Rebase présentera les conflits un commit à un moment où la fusion sera présent tout à la fois.

Donc la réponse courte est de choisir rebase ou de fusion basé sur ce que vous voulez que votre histoire de ressembler à.

Réponse Longue

Il ya quelques facteurs que vous devriez considérer lors du choix de l'opération à utiliser.

Est la branche que vous obtenez des changements de partagé avec d'autres développeurs à l'extérieur de votre équipe (par exemple, open source, public)?

Si si, ne pas rebase. Rebase détruit la direction générale et les développeurs auront cassé/incompatible dépôts à moins qu'ils utilisent git pull --rebase. C'est un bon moyen de contrarier d'autres développeurs de rapidement.

Comment qualifiés est à votre équipe de développement?

Rebase est une opération destructrice. Cela signifie que, si vous ne l'appliquent pas correctement, vous pourriez perdre le travail engagé et/ou de casser la cohérence des autres développeurs de dépôts.

J'ai travaillé sur des équipes où les développeurs sont tous venus d'un temps où les entreprises pouvaient se permettre un personnel dédié à face avec le branchement et la fusion. Les développeurs ne savent pas beaucoup sur Git et ne veulent pas en savoir beaucoup. Dans ces équipes, je ne risque pas d'en recommander la relocalisation pour une raison quelconque.

La direction elle-même représenter des informations utiles

Certaines équipes utilisent la branche par la fonctionnalité d'un modèle où chaque branche représente une fonction (ou de la correction ou de la sous-fonction, etc.) Dans ce modèle, la branche aide à identifier des ensembles de commits. Par exemple, on peut revenir rapidement une fonctionnalité en revenant de la fusion de la direction générale (pour être juste, c'est une opération rare). Ou diff d'une fonction par la comparaison de deux branches (les plus courantes). Cela permettrait de détruire la branche et ce ne serait pas facile.

J'ai également travaillé sur des équipes qui ont utilisé de la direction par développeur modèle (nous avons tous été là). Dans ce cas, la direction elle-même n'est pas de transmettre des informations supplémentaires (le commit a déjà l'auteur). Il n'y aurait pas de mal à la relocalisation.

Qui pourrait vous faire vouloir revenir les fusionner pour n'importe quelle raison?

De revenir (comme à défaire) un rebase est beaucoup plus difficile et/ou impossible (si cela avait des conflits) par rapport à l'idée de revenir à une fusion. Si vous pensez qu'il ya une chance que vous aurez envie de revenir ensuite utiliser la fusion.

Travaillez-vous sur une équipe? Si oui, êtes-vous prêt à prendre une approche du tout ou rien sur cette branche?

Rebase opérations doivent être tirées avec un correspondant git pull --rebase. Si vous travaillez par vous-même, vous pourriez être en mesure de se rappeler que vous devez utiliser au moment opportun. Si vous travaillez dans une équipe, ce sera très difficile à coordonner. C'est pourquoi la plupart rebase flux de travail vous recommandons d'utiliser rebase pour toutes les fusions (et git pull --rebase pour tous les tire).

Mythes Communs

De fusion détruit de l'histoire (les courges s'engage)

En supposant que vous avez la suite de fusion:

    B -- C
   /     \
  A--------D

Certaines personnes de l'état que la fusion "détruit" la validation de l'histoire, parce que si vous regardez le journal de seulement la branche master (A-D) vous manquez le important des messages de validation contenu dans B et C.

Si cela était vrai, nous n'aurions pas des questions de ce genre. Fondamentalement, vous verrez B et C, sauf si vous demandez explicitement de ne pas les voir (à l'aide de --premier-parent). C'est très facile d'essayer pour vous-même.

Rebase permet pour plus de sécurité/de plus simple fusionne

Les deux approches de fusion de façon différente, mais il n'est pas clair que l'on est toujours mieux que les autres et il peut dépendre du flux de travail du développeur. Par exemple, si un développeur a tendance à commettre régulièrement (par exemple, peut-être qu'ils commettent deux fois par jour au moment de la transition du travail à la maison), alors il pourrait y avoir beaucoup de validations pour une branche donnée. Beaucoup de ces livraisons pourraient ne ressemblera en rien le produit final (j'ai tendance à refactoriser ma démarche une fois ou deux fois par fonctionnalité). Si quelqu'un d'autre a été de travailler sur une zone de code et ils ont essayé de rebase mes modifications, il peut être fastidieux de fonctionnement.

Rebase est plus froid /sexy /plus professionnel

Si vous aimez alias rm à rm -rf pour "gagner du temps", alors peut-être rebase est fait pour vous.

Mes Deux Cents

Je pense toujours qu'un jour je vais venir à travers un scénario où git rebase est l'outil génial qui permet de résoudre le problème. Tout comme je pense que je vais venir à travers un scénario où git reflog est un outil génial qui permet de résoudre mon problème. J'ai travaillé avec git depuis plus de cinq ans maintenant. Il n'est pas arrivé.

Désordre histoires n'ont jamais vraiment été un problème pour moi. Je n'en fais pas il suffit de lire mon commettre l'histoire comme un passionnant roman. La plupart du temps, j'ai besoin d'une histoire que je vais utiliser git blâmer ou git coupent de toute façon. Dans ce cas, avoir la fusion commettre est vraiment utile pour moi, parce que si la fusion a introduit le problème de l'information significative pour moi.

Mise à jour (4/2017)

Je me sens obligé de dire que j'ai personnellement ramolli à l'aide de rebase bien que mon avis est toujours debout. J'ai été récemment à interagir beaucoup avec les Angulaire 2 projet. Ils ont utilisé rebase pour garder un très propre commettre l'histoire. Cela m'a permis de facilement voir ce que commettre fixe un défaut et si oui ou non qui s'engagent a été inclus dans un communiqué. Il sert comme un excellent exemple de l'utilisation de rebase correctement.

La fusion signifie: Créer un nouveau commit qui fusionne mes changements dans la destination.

Rebase signifie: Créer une toute nouvelle série de commits, à l'aide de mon ensemble actuel de commits que des conseils. En d'autres termes, le calcul de ce que mes modifications auraient regardé comme si j'avais commencé à faire du point je suis rebasage sur. Après cela, par conséquent, vous pourriez avoir besoin de re-tester vos modifications et pendant le rebase, vous peut-être avoir un peu de conflits.

Compte tenu de cela, pourquoi feriez-vous cela? Juste pour garder l'histoire du développement claire. Disons que vous travaillez sur la caractéristique X et lorsque vous avez terminé, vous fusionner vos modifications. La destination de disposer désormais d'un commit unique qui permettrait de dire quelque chose le long des lignes de "Ajout de la fonction X". Maintenant, au lieu de les fusionner, si vous relocalisée et ensuite fusionné, le développement de la destination de l'histoire contient toutes l'individu s'engage dans une seule logique de la progression. Cela rend l'examen de change par la suite beaucoup plus facile. Imaginer combien il est difficile que vous pouvez trouver en revue l'histoire du développement si 50 développeurs ont été la fusion de diverses fonctions de tous les temps.

Cela dit, si vous avez déjà poussé la direction, vous travaillez en amont, vous ne devriez pas cela, mais au lieu de fusion. Pour les branches qui n'ont pas été poussé en amont, rebase, de test et de fusion.

Une autre fois, vous pourriez souhaiter pour rebase est quand vous voulez pour se débarrasser de commits de votre branche avant de le pousser en amont. Par exemple: s'Engage à ce que d'introduire un peu de débogage de code dès le début, et d'autres s'engage plus loin que la propre code. La seule façon de le faire est par la réalisation d'une rebase interactif: git rebase -i <branch/commit/tag>

Mise à JOUR: Vous souhaitez également utiliser rebase lorsque vous utilisez Git pour l'interface d'un système de contrôle de version ne prend pas en charge non-linéaire de l'histoire (la subversion par exemple). Lors de l'utilisation de git-svn pont, il est très important que les modifications que vous réinsèrent dans la subversion sont une liste séquentielle de changements sur le dessus des modifications les plus récentes dans le coffre. Il y a seulement deux façons de le faire: (1) recréer Manuellement les modifications et (2) à l'Aide de la commande rebase, qui est beaucoup plus rapide.

UPDATE2 : Une autre façon de penser à un rebase est qu'il permet une sorte de cartographie de développement de style pour le style acceptée dans le référentiel que vous avez commis à l'. Disons que vous aimez à s'engager dans de tous petits morceaux. Vous avez un commit pour corriger une faute de frappe, un commit à se débarrasser de code inutilisé et ainsi de suite. Par le temps que vous avez terminé ce que vous devez faire, vous avez une longue série de commits. Maintenant, disons le dépôt que vous avez commis encourage les grands s'engage, donc pour le travail que vous faites, on pourrait s'attendre à l'une ou peut-être deux commits. Comment prenez-vous votre chaîne de livraisons et de les compresser à ce qui est prévu? Vous devez utiliser un rebase interactif et des courges, votre petit s'engage dans moins de plus gros morceaux. Le même est vrai si l'inverse était nécessaire - si votre style est un peu gros s'engage, mais l'opération a exigé de longues chaînes de petits commits. Vous pouvez utiliser un rebase d'en faire autant. Si vous avait fusionné au lieu de cela, vous avez maintenant greffé votre livraison de style sur le dépôt principal. Si il y a beaucoup de développeurs, vous pouvez imaginer combien il serait de suivre une histoire avec plusieurs commettre des styles après un certain temps.

UPDATE3: Does one still need to merge after a successful rebase? Oui, vous le faites. La raison en est que cela implique essentiellement un "décalage" de commits. Comme je l'ai dit ci-dessus, ces révisions sont calculés, mais si vous aviez 14 s'engage à partir du point de branchement, puis en supposant que rien ne va mal avec votre rebase, vous serez 14 s'engage à l'avance (le point vous êtes à la relocalisation sur) après le rebase est fait. Vous avez eu une branche avant de un rebase. Vous aurez une branche de la même longueur après. Vous avez encore le besoin de fusionner avant de publier vos modifications. En d'autres termes, cela autant de fois que vous le souhaitez (encore une fois, seulement si vous n'avez pas poussé vos modifications en amont). Fusionner seulement après que vous rebase.

Alors que la fusion est certainement la méthode la plus simple et la plus commune façon d'intégrer les changements, ce n'est pas le seul: Rebase est un moyen d'intégration.

Compréhension de Fusion un Peu Mieux

Quand Git effectue une opération de fusion, il cherche à trois s'engage à:

• (1) ancêtre Commun à l'engager Si vous suivez l'histoire de deux branches dans un projet, ils ont toujours au moins un commit en commun: à ce point dans le temps, les deux branches ont le même contenu, puis a évolué différemment.
• (2) + (3) les systèmes d'extrémité de chaque branche de L'objectif d'intégration est de combiner l'état actuel de deux branches. Par conséquent, leurs dernières révisions sont d'un intérêt particulier.
  La combinaison de ces trois engage entraînera l'intégration que nous visons.

D'avance rapide ou de Fusion de Commettre

Dans des cas très simples, l'une des deux branches n'ont pas de nouveaux commits depuis la ramification qui s'est passé - son dernier commit est encore l'ancêtre commun.

Dans ce cas, réaliser l'intégration est très simple: Git peut ajouter tous les commits de l'autre branche sur le dessus de l'ancêtre commun à commettre. Dans Git, cette forme la plus simple de l'intégration est appelé un "fast-forward" de fusion. Les deux branches puis de partager exactement la même histoire.

Dans beaucoup de cas, cependant, les deux branches progressé individuellement.

À faire de l'intégration de Git devrez créer un nouveau commit qui contient les différences entre eux - la fusion s'engager.

De l'homme s'Engage & Fusion s'Engage

Normalement, un commit est soigneusement créé par un être humain. C'est une unité appropriée qui encapsule seulement les modifications connexes et annote avec un commentaire.

Une fusion s'engager est un peu différent: au lieu d'être créé par un développeur, il est créé automatiquement par Git. Et au lieu de l'emballage d'un ensemble de modifications liées à l', son but est de connecter deux branches, comme un noeud. Si vous voulez comprendre une opération de fusion plus tard, vous avez besoin de prendre un coup d'oeil à l'histoire des deux branches et la validation correspondante graphique.

L'intégration avec git Rebase

Certaines personnes préfèrent aller sans une telle automatique de fusion s'engage. Au lieu de cela, ils veulent que le projet de l'histoire de la regarder comme si elle avait évolué en une seule ligne droite. Aucune indication demeure pas moins qu'il avait été divisée en plusieurs branches à un certain point.

Nous allons marcher à travers un rebase opération étape par étape. Le scénario est le même que dans les exemples précédents: nous voulons intégrer les modifications de la branche B de la direction générale-Un, mais maintenant, à l'aide de rebase.

Nous allons le faire en trois étapes

1. git rebase branch-A //syncs the history with branch-A
2. git checkout branch-A //change the current branch to branch-A
3. git merge branch-B //merge/take the changes from branch-B to branch-A

D'abord, Git va "annuler" tous les commits de la branche-Une qui s'est passé après les lignes ont commencé à se ramifier (après l'ancêtre commun à valider). Cependant, bien sûr, de ne pas les jeter: au lieu de cela, vous pouvez penser à ceux qui l'engage comme "enregistré à l'écart temporairement".

Ensuite, il applique les commits de la branche B que nous voulons intégrer. À ce stade, les deux branches exactement le même.

Dans l'étape finale, la nouvelle s'engage sur la branche-Un sont appliqué - mais sur une nouvelle position, sur le dessus de la intégrée de commits de la branche B (ils sont re-base).
Le résultat ressemble à du développement qui s'était passé dans une ligne droite. Au lieu d'un commit de fusion qui contient toutes les modifications combinées, l'original s'engager structure a été conservée.

Finalement, vous obtenez un nettoyage de la branche de la succursale d'Une sans indésirables et auto généré s'engage.

Remarque: Prises à partir de l'impressionnant post par git-tour. Le inconvénients de rebase est également une bonne lecture sur le même poste.

Cette réponse est largement orientée autour de Git Flow. Les tables ont été générés avec le beau Table ASCII Generator, et l'histoire des arbres avec ce merveilleux commande (alias comme git lg):

git log --graph --abbrev-commit --decorate --date=format:'%Y-%m-%d %H:%M:%S' --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%ad%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n''          %C(white)%s%C(reset) %C(dim white)- %an%C(reset)'

Les Tables sont dans l'ordre chronologique inverse pour être plus cohérent avec l'histoire des arbres. Voir aussi la différence entre git merge et git merge --no-ff première (généralement, vous souhaitez utiliser git merge --no-ff, car il rend votre histoire regarder de plus près à la réalité):

git merge

Commandes:

Time          Branch "develop"             Branch "features/foo"
------- ------------------------------ -------------------------------
15:04   git merge features/foo
15:03                                  git commit -m "Third commit"
15:02                                  git commit -m "Second commit"
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

Résultat:

* 142a74a - YYYY-MM-DD 15:03:00 (XX minutes ago) (HEAD -> develop, features/foo)
|           Third commit - Christophe
* 00d848c - YYYY-MM-DD 15:02:00 (XX minutes ago)
|           Second commit - Christophe
* 298e9c5 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git merge --no-ff

Commandes:

Time           Branch "develop"              Branch "features/foo"
------- -------------------------------- -------------------------------
15:04   git merge --no-ff features/foo
15:03                                    git commit -m "Third commit"
15:02                                    git commit -m "Second commit"
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

Résultat:

*   1140d8c - YYYY-MM-DD 15:04:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/foo' - Christophe
| * 69f4a7a - YYYY-MM-DD 15:03:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 2973183 - YYYY-MM-DD 15:02:00 (XX minutes ago)
|/           Second commit - Christophe
* c173472 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

---

git merge vs git rebase

Premier point: toujours fonctionnalités de fusion en développer, jamais rebase se développer à partir des caractéristiques. C'est une conséquence de la Règle d'or de la Relocalisation:

La règle d'or de la git rebase est de ne jamais l'utiliser sur public branches.

En d'autres termes:

Jamais rebase tout ce que vous avez poussé quelque part.

Je serais personnellement ajouter: sauf si c'est une branche de fonctionnalité et de vous ET de votre équipe sont conscients des conséquences.

Donc, la question de git merge vs git rebase s'applique presque exclusivement à la branche (dans les exemples suivants, --no-ff a toujours été utilisé lors de la fusion). Notez que depuis que je ne suis pas sûr qu'il y a une meilleure solution (un débat existe), je ne vais fournir comment ces deux commandes se comporter. Dans mon cas, je préfère utiliser git rebase comme il produit une plus belle histoire de l'arbre 🙂

Entre les branches

git merge

Commandes:

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- --------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git merge --no-ff features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

Résultat:

*   c0a3b89 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 37e933e - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| *   eb5e657 - YYYY-MM-DD 15:07:00 (XX minutes ago)
| |\            Merge branch 'features/foo' into features/bar - Christophe
| * | 2e4086f - YYYY-MM-DD 15:06:00 (XX minutes ago)
| | |           Fifth commit - Christophe
| * | 31e3a60 - YYYY-MM-DD 15:05:00 (XX minutes ago)
| | |           Fourth commit - Christophe
* | |   98b439f - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \ \            Merge branch 'features/foo' - Christophe
| |//
|/| /
| |/
| * 6579c9c - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 3f41d96 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/           Second commit - Christophe
* 14edc68 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git rebase

Commandes:

Time           Branch "develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09   git merge --no-ff features/foo
15:08                                                                    git commit -m "Sixth commit"
15:07                                                                    git rebase features/foo
15:06                                                                    git commit -m "Fifth commit"
15:05                                                                    git commit -m "Fourth commit"
15:04                                    git commit -m "Third commit"
15:03                                    git commit -m "Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m "First commit"

Résultat:

*   7a99663 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 708347a - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * 949ae73 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * 108b4c7 - YYYY-MM-DD 15:05:00 (XX minutes ago)
| |           Fourth commit - Christophe
* |   189de99 - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| |/
| * 26835a0 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * a61dd08 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/           Second commit - Christophe
* ae6f5fc - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

De develop à une branche

git merge

Commandes:

Time           Branch “develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09                                                                    git commit -m “Sixth commit"
15:08                                                                    git merge --no-ff development
15:07   git merge --no-ff features/foo
15:06                                                                    git commit -m “Fifth commit"
15:05                                                                    git commit -m “Fourth commit"
15:04                                    git commit -m “Third commit"
15:03                                    git commit -m “Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m “First commit"

Résultat:

*   9e6311a - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 3ce9128 - YYYY-MM-DD 15:09:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| *   d0cd244 - YYYY-MM-DD 15:08:00 (XX minutes ago)
| |\            Merge branch 'develop' into features/bar - Christophe
| |/
|/|
* |   5bd5f70 - YYYY-MM-DD 15:07:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| * | 4ef3853 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| | |           Third commit - Christophe
| * | 3227253 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|//           Second commit - Christophe
| * b5543a2 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * 5e84b79 - YYYY-MM-DD 15:05:00 (XX minutes ago)
|/           Fourth commit - Christophe
* 2da6d8d - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git rebase

Commandes:

Time           Branch “develop"              Branch "features/foo"           Branch "features/bar"
------- -------------------------------- ------------------------------- -------------------------------
15:10   git merge --no-ff features/bar
15:09                                                                    git commit -m “Sixth commit"
15:08                                                                    git rebase development
15:07   git merge --no-ff features/foo
15:06                                                                    git commit -m “Fifth commit"
15:05                                                                    git commit -m “Fourth commit"
15:04                                    git commit -m “Third commit"
15:03                                    git commit -m “Second commit"
15:02   git checkout -b features/bar
15:01   git checkout -b features/foo
15:00   git commit -m “First commit"

Résultat:

*   b0f6752 - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 621ad5b - YYYY-MM-DD 15:09:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * 9cb1a16 - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * b8ddd19 - YYYY-MM-DD 15:05:00 (XX minutes ago)
|/           Fourth commit - Christophe
*   856433e - YYYY-MM-DD 15:07:00 (XX minutes ago)
|\            Merge branch 'features/foo' - Christophe
| * 694ac81 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * 5fd94d3 - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/           Second commit - Christophe
* d01d589 - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

---

Notes

git cherry-pick

Lorsque vous avez juste besoin d'un commit, git cherry-pick est une solution sympa (le -x option ajoute une ligne qui dit "(cerise choisi de s'engager...)" à l'origine le message de validation de corps, de sorte qu'il est généralement une bonne idée de l'utiliser - git log <commit_sha1> pour le voir):

Commandes:

Time           Branch “develop"              Branch "features/foo"                Branch "features/bar"           
------- -------------------------------- ------------------------------- -----------------------------------------
15:10   git merge --no-ff features/bar                                                                            
15:09   git merge --no-ff features/foo                                                                            
15:08                                                                    git commit -m “Sixth commit"             
15:07                                                                    git cherry-pick -x <second_commit_sha1>  
15:06                                                                    git commit -m “Fifth commit"             
15:05                                                                    git commit -m “Fourth commit"            
15:04                                    git commit -m “Third commit"                                             
15:03                                    git commit -m “Second commit"                                            
15:02   git checkout -b features/bar                                                                              
15:01   git checkout -b features/foo                                                                              
15:00   git commit -m “First commit"                                                                              

Résultat:

*   50839cd - YYYY-MM-DD 15:10:00 (XX minutes ago) (HEAD -> develop)
|\            Merge branch 'features/bar' - Christophe
| * 0cda99f - YYYY-MM-DD 15:08:00 (XX minutes ago) (features/bar)
| |           Sixth commit - Christophe
| * f7d6c47 - YYYY-MM-DD 15:03:00 (XX minutes ago)
| |           Second commit - Christophe
| * dd7d05a - YYYY-MM-DD 15:06:00 (XX minutes ago)
| |           Fifth commit - Christophe
| * d0d759b - YYYY-MM-DD 15:05:00 (XX minutes ago)
| |           Fourth commit - Christophe
* |   1a397c5 - YYYY-MM-DD 15:09:00 (XX minutes ago)
|\ \            Merge branch 'features/foo' - Christophe
| |/
|/|
| * 0600a72 - YYYY-MM-DD 15:04:00 (XX minutes ago) (features/foo)
| |           Third commit - Christophe
| * f4c127a - YYYY-MM-DD 15:03:00 (XX minutes ago)
|/           Second commit - Christophe
* 0cf894c - YYYY-MM-DD 15:00:00 (XX minutes ago)
            First commit - Christophe

git pull --rebase

Pas sûr que je peux l'expliquer mieux que Derek Gourlay... en fait, l'utilisation git pull --rebase au lieu de git pull 🙂 Ce qu'il manque dans l'article, cependant, est que vous pouvez l'activer par défaut:

git config --global pull.rebase true

git rerere

Encore, joliment expliqué ici. Mais en des termes simples, si vous l'activez, vous n'aurez pas à résoudre le conflit plusieurs fois plus.

Git rebase est utilisé pour faire de l'embranchement des chemins de l'histoire propre et référentiel de structure linéaire.

Il est également utilisé pour garder les succursales créées par vous-privé, comme après la relocalisation et en poussant les changements de serveur, si vous supprimez votre branche, il n'y aura pas de preuve de la branche qui vous avez travaillé. Si votre branche est maintenant votre intérêt local.

Après cela nous également de se débarrasser d'un supplément de commettre ce qui nous permet de voir si nous ne normal de fusion.

Et oui on a encore besoin de faire fusionner les après le succès d'un rebase comme commande rebase met juste votre travail sur le dessus de la branche que vous avez mentionné lors de rebase dire maître et fait de la première validation de votre branche comme un descendant direct de la branche master. Cela signifie que nous pouvons maintenant faire une avance rapide de fusion et d'apporter des changements à partir de cette branche à branche master.

Il a été expliqué de nombreuses fois ce rebase et ce que l'opération de fusion est, mais quand utiliser quoi?

Lors de l'utilisation de rebase?

• lorsque vous n'avez pas poussé la direction générale /personne ne travaille sur elle
• vous voulez l'histoire complète
• vous voulez éviter tous les auto-généré "fusionné .." messages de commit

Que git rebase les changements de l'histoire. Par conséquent, vous ne devriez pas l'utiliser quand quelqu'un d'autre travaille sur la même branche /si vous avez poussé. Mais si vous avez une agence locale, vous pouvez effectuer une fusion rebase maître avant de passer à votre succursale de retour en master de garder un nettoyeur de l'histoire. Ce faisant, après la fusion dans la branche principale, il ne sera pas visible que vous avez utilisé une branche dans la branche master - l'histoire est plus "propre" que vous n'avez pas d'auto-généré "fusionné .. ", mais encore l'histoire complète dans votre branche master sans avoir généré automatiquement "fusionné.." s'engage. Assurez-vous, toutefois, vous utilisez git merge feature-branch --ff-only pour s'assurer de l'absence de conflits création d'un seul commettre lorsque vous fusionnez votre fonction retour à la page principale. Ce qui est intéressant si vous utilisez la fonctionnalité de branches pour chaque tâche que vous travaillez sur vous accéder à l'historique de la branche, mais pas un "fusionné .." s'engager

Un deuxième scénario serait, si vous ramifiée à partir d'une branche et que vous voulez savoir ce qui a changé dans la branche principale. cela vous donne l'information, puisqu'il comprend tous les commettre.

Lors de l'utilisation de fusion?

• lorsque vous avez poussé la direction générale /autres sont trop
• vous n'avez pas besoin de toute l'histoire
• simplement la fusion est assez bonne pour vous

Quand vous n'en avez pas besoin ou envie d'avoir toute l'histoire d'une branche de fonctionnalité dans votre branche master ou si d'autres personnes travaillent sur la même branche /vous avez poussé. Si vous voulez toujours avoir l'histoire, juste de fusion maître en fonction de la branche avant de la fusion de branche en maître. Il en résultera une avance rapide de fusion où vous avez l'histoire de la branche dans votre master (y compris la fusion s'engager dans votre branche, parce que vous avez fusionné master en it).