Je ne peux tout simplement pas comprendre cela. J'ai beaucoup lu sur le Web et dans les livres et quelque chose ne reste pas dans ma tête. Quelqu'un peut-il me donner s'il vous plaît la version factice de ce qui suit:
git fetch vs pull et fusion de git vs rebase
fetch permettra de télécharger toutes les modifications de la branche distante, la mise à jour de votre référentiel de données, mais en laissant à votre succursale locale inchangé.
pull effectuera une fetch , et de plus, merge les changements dans votre succursale locale.
Quelle est la différence? pull mises à jour de votre branche locale avec les modifications de l'tiré de la branche. Un fetch n'avance pas à votre succursale locale.
Compte tenu de la suite de l'histoire:
C---D---E local / A---B---F---G à distance
merge joint deux développement de leurs histoires. Il le fait en relisant les changements qui ont eu lieu sur votre succursale locale après avoir divergé sur le dessus de la branche distante, et enregistrer le résultat dans un nouveau commit. Cette opération préserve l'ascendance de chaque commit.
L'effet d'un merge sera:
C---D---E local / \ A---B----F--G---H distance
rebase faudra s'engage à ce que exister dans votre succursale locale et ré-appliquer sur le dessus de la branche distante. Cette opération de ré-écrit les ancêtres de votre local s'engage.
L'effet d'un rebase sera:
C' - D' - E' local / A---B---F---G à distance
Quelle est la différence? Un merge ne change pas l'ascendance de commits. Un rebase
réécrit l'ascendance de votre local s'engage.
Fetch vs Tirez
Git fetch juste les mises à jour de votre dépôt de données, mais un git pull fondamentalement effectuer une extraction puis de fusionner la branche tiré
Quelle est la différence entre la commande git pull et git fetch?
Fusion vs Rebase
(à partir de http://blog.sourcetreeapp.com/2012/08/21/merge-or-rebase/)
La fusion apporte deux lignes de développement tout en préservant la l'ascendance de chaque validation de l'histoire.
En revanche, le changement d'année de base unifie les lignes de développement par la ré-écriture modifications de la source direction générale de sorte qu'ils apparaissent comme les enfants de la destination de la branche efficacement en prétendant que ces commits ont été écrit sur le dessus de l'agence de destination.
EDIT:
Vérifiez ceci: http://pcottle.github.com/learnGitBranching/
C'est un jeu agréable, qui ont juste été posté sur HN (http://news.ycombinator.com/item?id=5236409), qui enseigne beaucoup de ramification/fusion des astuces. Je crois qu'il sera très utile dans cette affaire.
tirez vs chercher:
La façon dont je le comprends, c'est qu' git pull est tout simplement un git fetch suivie par git merge. I. e. vous allez chercher les modifications d'une branche distante et puis les fusionner dans le courant de la branche.
fusion vs rebase:
Une fusion va faire comme la commande dit; fusionner les différences entre la branche et la branche (dans le courant de la branche). I. e. la commande git merge another_branch sera la fusion another_branch dans la branche courante.
Un rebase fonctionne un peu différemment et est plutôt cool. Disons que vous exécuter la commande git rebase another_branch. Git va d'abord trouver la dernière version commune entre le courant de la branche et de l' another_branch. I. e. le point avant que les branches ont divergé. Puis git déplacera ce divergences de point à la tête de l' another_branch. Enfin, tous les commits de la branche courante depuis l'origine divergences de point sont relus à partir de la nouvelle divergences de point. Cela crée un très propre histoire, avec moins de branches et les fusions.
Cependant, il n'est pas sans embûches! Depuis la version de l'histoire est "réécrit", vous ne devriez faire cela si les commits n'existe que dans votre repo git local. C'est: ne Jamais faire cela si vous avez poussé la s'engage à une distance de repo.
L'explication sur le changement d'année de base donnée dans ce livre en ligne est assez bonne, avec facile-à-comprendre les illustrations.
tirez avec la relocalisation au lieu de fusionner
Je suis en fait à l'aide de rebase beaucoup, mais il est habituellement en combinaison avec d'pull:
git pull --rebase
va récupérer à distance des changements et rebase au lieu de fusionner. I. e. il va de relecture de tous vos locaux commits depuis la dernière fois que vous avez effectué un pull. Je trouve cela beaucoup plus propre que de faire une traction normales avec la fusion, ce qui permettra de créer un supplément de s'engager avec les fusions.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
