1. Les deux façons et les différences du projet git pull

1. Méthode :

Http : le projet de clonage via http n'a pas besoin de lier manuellement ssh sur git, mais doit uniquement saisir le numéro de compte et le mot de passe lors du clonage ;
SSH : clonez le projet via ssh, vous devez lier manuellement la clé ssh

2. Différence

La méthode Http convient à l'accès anonyme, convient aux projets open source et peut être facilement clonée et lue par d'autres (mais sans autorisation push);
La méthode Ssh convient au développement de projets internes, tant que la clé SSH est configurée, les opérations de clonage et de poussée peuvent être réalisées librement.

2. La différence entre git rebase et git merge

Les commandes git rebase et git merge traitent le même problème. Les deux commandes sont utilisées pour intégrer les modifications d'une branche à une autre, elles font simplement la même chose de différentes manières.

Supposons maintenant qu'un nouveau commit sur la branche master soit lié à la fonctionnalité sur laquelle vous travaillez. Pour fusionner de nouveaux commits dans votre branche de fonctionnalité, vous avez deux options : fusionner ou rebaser.

2.1, fusionner

Le principe de la fusion est de trouver les commits ancêtres de ces deux branches, et d'effectuer une comparaison à trois voies et de fusionner sur
les derniers commits des deux branches . Trois commits sont comparés :

En comparant commit6 et commit2, si la valeur de hachage du fichier est différente, et en comparant commit5 et commit2 en même temps, et en trouvant le même, cela signifie que seul commit6 a modifié le fichier. Dans ce cas, il sera fusionné directement sans incitant

En comparant commit6 et commit2, si la valeur de hachage du fichier est différente, et en comparant commit5 et commit2 en même temps, la valeur de hachage est différente, indiquant que les deux branches ont modifié le même fichier, un conflit sera déclenché, et nous avons besoin fusionner manuellement

Après la fusion finale, un nouveau commit7 sera généré.

2.1.1. Résumé

L'utilisation de la fusion est une bonne idée car il s'agit d'une opération non destructive. Les succursales existantes ne seront en aucun cas modifiées. Cela évite les pièges potentiels créés par les opérations de changement de base (voir ci-dessous).

D'un autre côté, cela signifie également que chaque fois que la branche develop doit fusionner des modifications en amont, elle produira un commit de fusion supplémentaire. Cela peut sérieusement polluer l'historique de votre branche de développement si les commits principaux sont très actifs. Bien que ce problème puisse être atténué avec l'option avancée git log , il peut être difficile pour les autres développeurs de comprendre l'historique du projet.

2.2, renard

Cela develop déplace la branche entière vers master l'avant de la branche, intégrant efficacement master les commits sur toutes les branches. Cependant, contrairement aux commits de fusion, rebase réécrit l'historique du projet en créant de nouveaux commits pour chaque commit dans la branche d'origine.

Le principal avantage du rebase est un historique de projet plus propre. Premièrement, cela élimine les commits de fusion inutiles requis par git merge ; deuxièmement, comme vous pouvez le voir dans l'image ci-dessus, rebase produit un historique de projet parfaitement linéaire, et vous ne pouvez pas avoir de fourches sur la branche develop. commit initial du projet. Cela facilite la navigation et la visualisation des projets avec les commandes git log, git bisect et gitk.

Cependant, pour un tel historique de commit, nous devons peser sa "sécurité" et sa "traçabilité". Si vous ne suivez pas [les règles d'or de Rebase], la réécriture de l'historique du projet peut être désastreuse pour votre workflow collaboratif. De plus, le rebasage perd le contexte du commit de fusion, vous ne pouvez donc pas voir quand les modifications en amont ont été fusionnées dans develop.

3. Résumé des avantages et des inconvénients de la fusion et du rebasage

rebase : après la fusion, la mappe de branche semble bonne, avec une seule ligne, mais s'il y a un conflit pendant le processus de fusion, ce sera plus gênant (pendant le processus de rebase, si un commit a un conflit, le prochain commit est également très susceptible d'avoir un conflit, et un rebase peut avoir à résoudre plusieurs conflits) ;
fusionner : après la fusion, la carte de branche n'est pas belle et un tas de lignes sont entrelacées, mais s'il y a un conflit dans la fusion, vous n'avez besoin de le résoudre qu'une seule fois ;
En général, si la branche ancêtre commune de la branche fusionnée diffère d'un ou deux ou deux ou trois commits, utilisez rebase. Après tout, le rebase a l'air bien après la fusion et la carte de branche est claire. S'il y a beaucoup de commits différents du branche ancêtre commune, cela signifie que la rebase est possible. S'il y a plusieurs conflits, la fusion sera très gênante. À ce stade, utilisez la fusion

Problèmes avec le projet git pull