Pousser un scénario à l’extrême est une mauvaise manière d’argumenter.

Tout d'abord, quel est le but de la soumission ? S'il s'agit simplement de synchroniser le code avec les autres, alors git n'a vraiment aucun point fort. Même la soumission hors ligne peut être mal comprise, ce qui est une lacune.

Je pense personnellement que le but de la soumission est de stocker temporairement le code (gestion des versions pour faciliter le rollback ultérieur de Shenma), le second est de servir de nœud d'étape du code (cette fonction est terminée, soumettez-la), et la troisième consiste à le soumettre au serveur Sync et à le partager avec d'autres.

La soumission hors ligne de Git peut très bien accomplir un ou deux des objectifs ci-dessus. Et comme il est soumis hors ligne, vous pouvez facilement modifier l'enregistrement de soumission avant de le synchroniser avec le serveur. À quoi sert-il ? Par exemple, j'ai écrit une méthode et elle fonctionne, mais je veux la refactoriser, mais je ne suis pas sûr qu'elle fonctionnera correctement après la refactorisation, donc je soumets d'abord une version afin de pouvoir la restaurer si la refactorisation échoue. Une fois la refactorisation terminée, je le soumettrai à nouveau. À ce stade, il y a deux soumissions de la même fonction, et vous souhaiterez peut-être que les autres ne voient qu'une seule soumission « Fonction XX terminée », afin que vous puissiez facilement fusionner les deux soumissions. Après la fusion finale, le référentiel de code est très propre. Tous les enregistrements de soumission sont soumis car ils doivent vraiment être soumis. Ces soumissions peuvent être écrites directement dans les notes de version sans que « Test XXX » ou « Try XXX » n'apparaissent. Sur la base du même résultat, vous pouvez également soumettre le code écrit une fois à plusieurs reprises. Par exemple, si j'écris trois fonctions, je peux choisir de le soumettre trois fois et enfin de le synchroniser sur le serveur, vous (écrivez quand. il n'y a pas de réseau Le code) ne peut être soumis qu'une seule fois, puis écrire "Remplissez trois fonctions A, B et C". Cela ne permet pas aux autres de voir votre code, ni ne favorise l'annulation de A, B, et C respectivement.

La soumission hors ligne de Git apporte donc de la flexibilité. Cela ne signifie pas qu'avec la soumission hors ligne, je n'ai pas besoin de serveur, Air terminera automatiquement le travail collaboratif pour moi. C'est ce que je voulais dire lorsque je disais au début : « Pousser une scène à l'extrême est une mauvaise méthode d'argumentation. » Par rapport à svn, git a plus de méthodes collaboratives et est plus flexible, mais il ne peut pas éviter le problème de collaboration. Vous devez toujours collaborer et fusionner les codes.

Dans le processus de fusion de codes, tout comme SVN, des conflits seront également rencontrés, c'est donc toujours une bonne habitude de synchroniser le code avec le serveur en temps opportun si les conditions le permettent. Cependant, comme git est une version de suivi basée sur le contenu et que svn est une version de base de suivi de fichiers, git merge est beaucoup plus fiable que svn. Autrement dit, dans les mêmes circonstances, git est beaucoup moins susceptible de rencontrer des conflits que svn.

Enfin, grâce à la fonctionnalité de soumission hors ligne de git, et au fait que les branches git sont particulièrement simples à utiliser, vous pouvez également implémenter des fonctions de gestion multi-branches locales, c'est-à-dire que lorsque vous travaillez sur une fonction, vous pouvez ouvrez une branche localement, puis soumettez-la localement, puis fusionnez-la et transférez-la vers le serveur. Pour d'autres, cette branche n'existe pas, mais pour vous, vous pouvez changer d'état de fonctionnement à tout moment (écrire de nouvelles fonctionnalités ou revenir en arrière). pour corriger des bugs). SVN peut également supprimer des branches, mais ses branches ne peuvent pas exister uniquement localement. Si la collaboration entre branches est adoptée, il y aura beaucoup de branches, dont certaines n'auront pas besoin de s'en soucier. Ce qui est encore plus gênant, c'est que si vous êtes à mi-chemin de l'écriture d'une nouvelle fonctionnalité et que vous devez revenir en arrière et corriger des bugs, vous ne pouvez soumettre que le code inachevé au serveur svn. À mon avis personnel (soumettre le code inachevé au serveur du référentiel). C'est un très mauvais comportement, mais avec git, parce que la branche est hors ligne, après l'avoir soumise, je reviens pour corriger le bug, puis je reviens, et une fois la fonction terminée, je fusionne les enregistrements de soumission et tout est parfait.

Si les deux parties modifient des fichiers différents ou des parties différentes du même fichier, git peut les fusionner automatiquement.

Si la même partie du même fichier est modifiée, git ne peut pas fusionner automatiquement. Cette situation est appelée "conflit". Git listera les dernières versions des deux parties, puis la personne qui a effectué la fusion (dans l'exemple). Oui C), modifier manuellement.

Dans le développement réel, si deux personnes ajoutent simplement des fonctions à ce fichier, elles peuvent être fusionnées automatiquement. Le conflit se produit principalement lorsque la même ligne est modifiée.

Réponse à compléter :

De nombreuses introductions soulignent que git peut être validé hors ligne, ce qui est destiné à être comparé à svn. Dans svn, seul le serveur dispose d'un référentiel complet et l'historique du code du client n'est pas complet. Chaque client dans git est un référentiel complet, et les opérations push et pull sont en fait une synchronisation entre plusieurs référentiels complets.

L'avantage est que vous n'avez pas peur que le serveur raccroche ou se perde. Tout le monde dispose d'une bibliothèque de versions complète. C'est aussi le point de départ pour Linus pour développer git (Linux est un projet open source distribué à plusieurs personnes). collaboration). L'inconvénient est la gestion des autorisations. Pire, tout le monde dispose d'un référentiel complet, ce qui peut entraîner une fuite accidentelle du code (toutes les modifications de l'historique).

Enfin j'ai une question à laquelle je peux bien répondre

Parlons d’abord de l’hypothèse de la question :

C a arrêté d'interagir avec la télécommande à partir du 6ème jour et a commencé à jouer tout seul. Qu'est-ce que c'est ? Ceci n'est pas distribué. Distribué signifie que lorsque le réseau est disponible, cela ne signifie pas qu'il ne se synchronise pas avec la télécommande après quelques jours ;

, alors ce fichier est rarement modifié (ou la même ligne est rarement modifiée), similaire à GlobalFunction.php sous Python, parfois c'est juste un nouveau Vous le ferez ne modifiez la variable setup.py que lorsque la version est publiée version ;

a une branche appelée : foo, alors A, B et C. peut se développer de manière collaborative. Parfois, des branches locales seront créées localement sur la base de cette branche commune master. Par exemple, la branche locale de A s'appelle master, celle de B s'appelle : a-dev et celle de C s'appelle b-dev. ça s'est produit ? c-dev

git checkout -b xxx origin/master # xxx 代表 `a-dev` 等

Deuxièmement, parlons de la fusion évoquée par la question :

localement basée sur master, alors C peut toujours mettre à jour la branche principale locale sans affecter la branche locale c-dev (et à ce moment vous pouvez toujours être sur le c-dev succursale) : c-dev

git pull origin master:master

local est mis à jour, comment cela sera-t-il reflété dans master ? C'est simple, GIT a pensé pour vous : c-dev

git rebase master # 此时你在 `c-dev` 分支

échoue ; 2. Aucun conflit (peut être automatiquement rebase), le dernier statut local merge est différent de local master Fusionner c-dev

S'il échoue, cela s'appelle un conflit ; il fait généralement référence à différentes soumissions qui modifient le). même fichier du même fichier. Les lignes (plusieurs lignes) de contenu obligent les développeurs à résoudre eux-mêmes les conflits merge ;

Résumé personnel

Branch est la fonctionnalité phare de GIT qui le distingue des autres systèmes de contrôle de version centralisés (

) ; killer feature est la fonctionnalité phare de la branche GIT ; les fonctionnalités distribuées de GIT sont indissociables des bonnes fonctionnalités de branche de GIT ; rebase

Lorsqu'un conflit survient, SVN compare ligne par ligne, tandis que Git enregistre les opérations, telles que l'ajout d'une ligne, la suppression d'une ligne ou la modification d'une ligne, afin que le processus de fusion soit plus facile

Le problème que vous avez mentionné ne peut être résolu que via les succursales

En termes simples, il peut être possible ou non de fusionner automatiquement.
Chaque commit dans Git enregistre une différence. Vous pouvez simplement afficher un commit et y jeter un œil. Le diff essaiera de faire correspondre plusieurs lignes avant et après la ligne modifiée d'origine. S'il peut correspondre, le diff peut être automatiquement fusionné.
Par exemple, si le correctif de C modifie une valeur dans la cinquième ligne, celle-ci n'est pas validée. A et B ont ajouté de nouvelles fonctions à GlobalFunction.php. Ces fonctions sont ajoutées à la fin du fichier. Ensuite, lorsque C fusionne, Git peut terminer la fusion via Cherry-pick.
Si les deux parties ont modifié le même endroit, le conflit devra être résolu manuellement.